I keep encountering BBC tickets for modules which have code hosted on
github, but which have no actual way to build the code in the repo
because they use Dist::Zilla and expect Dist::Zilla to generate it all
pre-release. This is fine for joe-random hacker worker on their own or
in a small team with agreed build conventions and requirements. It is
a total nightmare when you are someone like me who really has no
interest in Dist::Zilla and who doesn't want to have to learn it just
to fix your module when it breaks due to a core change.
The way Dist::Zilla works makes it very difficult and time consuming
to deal with modules that use it. It means I have to build and install
a latest perl, then install Dist::Zilla and all its dependencies
(takes about an hour or more?), and then i have to go read the docs on
Dist::Zilla on how to get it to do anything useful. Basically it makes
fixing bugs a serious burden instead of being a pleasurable session of
debugging and puzzle solving. I mean a Dist::Zilla based repo
typically doesn't even include a file that says what to do with the
repo to get it to build. I know I am supposed to run some "dzil"
command, but I tend to have to reread the docs to remember what the
heck that command is. It just seems like Dist::Zilla is *designed* to
be hostile towards third party builders who aren't used to the
toolchain.
I really am reaching the point where I say "I don't do BBC support for
modules hosted on GitHUb that use Dist::Zilla." Module::Build is bad
enough, but Dist::Zilla is much much worse. I don't want to be this
person, if I break your code by a core change I really strongly
believe I should be involved in fixing it. But when people build their
modules using Dist::Zilla that support becomes much more costly to
provide, and frankly the frustration to reward seems wildly out of
sync with each other, especially the reward goes to someone else, but
I get to keep all the frustration.
I don't know if anyone cares about this, but I feel sure that
Dist::Zilla could be changed to be much more friendly to people who
will be building other peoples repos. One thing that comes to mind is
maybe someone who knows Dist::Zilla can write a tool for core which
can "de-fang the zilla" in a github repo by downloading the latest
version of the release from CPAN and then inserting the build files
into the repo that contains the code. (Waves hands.) Or whatever, I
don't care really, I just don't think I should have to wait an hour
for cpanm to install half of CPAN to even be able to compile the code,
Anyway, thoughts and help would be appreciated here.
cheers,
Yves
cc'ed Andreas on this as he maybe has some thoughts on this and he
tends to be the person I get my BBC reports from.
--
perl -Mre=debug -e "/just|another|perl|hacker/"
github, but which have no actual way to build the code in the repo
because they use Dist::Zilla and expect Dist::Zilla to generate it all
pre-release. This is fine for joe-random hacker worker on their own or
in a small team with agreed build conventions and requirements. It is
a total nightmare when you are someone like me who really has no
interest in Dist::Zilla and who doesn't want to have to learn it just
to fix your module when it breaks due to a core change.
The way Dist::Zilla works makes it very difficult and time consuming
to deal with modules that use it. It means I have to build and install
a latest perl, then install Dist::Zilla and all its dependencies
(takes about an hour or more?), and then i have to go read the docs on
Dist::Zilla on how to get it to do anything useful. Basically it makes
fixing bugs a serious burden instead of being a pleasurable session of
debugging and puzzle solving. I mean a Dist::Zilla based repo
typically doesn't even include a file that says what to do with the
repo to get it to build. I know I am supposed to run some "dzil"
command, but I tend to have to reread the docs to remember what the
heck that command is. It just seems like Dist::Zilla is *designed* to
be hostile towards third party builders who aren't used to the
toolchain.
I really am reaching the point where I say "I don't do BBC support for
modules hosted on GitHUb that use Dist::Zilla." Module::Build is bad
enough, but Dist::Zilla is much much worse. I don't want to be this
person, if I break your code by a core change I really strongly
believe I should be involved in fixing it. But when people build their
modules using Dist::Zilla that support becomes much more costly to
provide, and frankly the frustration to reward seems wildly out of
sync with each other, especially the reward goes to someone else, but
I get to keep all the frustration.
I don't know if anyone cares about this, but I feel sure that
Dist::Zilla could be changed to be much more friendly to people who
will be building other peoples repos. One thing that comes to mind is
maybe someone who knows Dist::Zilla can write a tool for core which
can "de-fang the zilla" in a github repo by downloading the latest
version of the release from CPAN and then inserting the build files
into the repo that contains the code. (Waves hands.) Or whatever, I
don't care really, I just don't think I should have to wait an hour
for cpanm to install half of CPAN to even be able to compile the code,
Anyway, thoughts and help would be appreciated here.
cheers,
Yves
cc'ed Andreas on this as he maybe has some thoughts on this and he
tends to be the person I get my BBC reports from.
--
perl -Mre=debug -e "/just|another|perl|hacker/"