It is a build tool, which becomes a prerequisite when trying to fix a bug in code maintained by someone who uses it. I get it, if you are developing many cpan modules it makes sense, it makes your life easier. If you are just coming along and trying to fix a trivial problem/provide a trivial enhancement, the barrier for participation just jumped a few levels in terms of ease. For a long time one of the plugins (I can't remember which) frequently used by such developers was broken, so the long (as it was then, on a low powered machine I was using) installation time was all wasted, due to said bug. The plugin in question required patching manually at the time. From talking to other users it's a real turn off in terms of participation. I can see both sides of the coin here, but I'd never recommend this path for someone in Lady_Aleenas shoes.
| [reply] |
It's pretty rare to need Dist::Zilla to provide a patch for someone else's distribution.
If they've got version control, make a clone of it, make your changes to the files in lib/bin/whatever, use prove -l ./t to run the test suite, and if it passes, submit your changes.
If no version control, untar the latest tarball from CPAN, and do the same.
If you're not going to build a tarball of your fixed version, you probably won't need Dist::Zilla.
| [reply]
[d/l] |
I disagree.
Many Dist::Zilla project only have a dist.int and no Makefile.PL, so you will need the whole bloody suite to get started anyway.
However I applaud people using something to make their dist meet every standard and make their own lives easier to maintain and distribute their modules, IMHO Dist::Zilla is a (very) bad part of the toolchain to draw in fresh blood or make it easier for others (not using it) to submit changes.
I have not seen a project that uses Dist::Zilla where I could get away without Dist::Zilla installed
Enjoy, Have FUN! H.Merijn
| [reply] |
