That's exactly why I put that shit in an isolated environment. For me it's often worth it to wait the 30 minutes to install xD... but no, this would totally blow out any respectible work space. This comes into perspective when one realizes that it's not a prereq for your module, it's a build/dev environment. I am sure you know that, but that is fuzzy for most (was for me, anyway). | [reply] |
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] |
