Re^2: Convincing Module::Install to put stuff in inc/ (zilla--)

I don't use Dist::Zilla myself, and don't have it on my machine, but I've still patched Dist::Zilla-based modules. After all, even without Dist::Zilla installed, I can still edit the modules in 'lib', can't I? I can still edit the code.

OK, so they might be using Pod::Weaver to add boilerplate headers and footers to their pod, but chances are the documentation for the functions/methods/etc is still plain old pod, and I can edit that too.

And maybe I can't generate the Makefile for make test, but I can still run prove -w -Ilib t/* xt/*, which is sufficient in most non-XS cases.

perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

Comment on Re^2: Convincing Module::Install to put stuff in inc/ (zilla--) Select or Download Code

Replies are listed 'Best First'.
Re^3: Convincing Module::Install to put stuff in inc/ (zilla--) by tye (Sage) on May 26, 2012 at 17:48 UTC
Ah, you are mostly talking to brian d foy's points. I don't have experience trying to patch a Dist::Zilla module beyond having noticed that several mundane things that I'd normally do to try to start such a process run into a lack of Dist::Zilla and effectively stopped me. Brian said something about even the module code is turned into a template. Perhaps he didn't realize that the template mostly usually doesn't impact the code? I wouldn't know as I haven't surveyed any Dist::Zilla modules on that point. I don't know how many he has vs. how many you have. The author of a Dist::Zilla-using module that was present didn't disagree with brian's points. He even mentioned wanting to remove the Dist::Zilla dependency and not being sure even how to do that (I thought he should write a Dist::Zilla plug-in that removes the dependency for you). Preventing others from even doing "make test" is a pretty big roadblock. Sure, for many modules you can get away with skipping the "make" step and just hope that "perl -Ilib t/blah" actually works immediately. That certainly isn't my habit or assumption. I know of at least one module of mine (not yet on CPAN) where that assumption doesn't hold. So, when somebody hits that roadblock, they might decide to dive in and figure out how they can work around having no "make test". Thanks for noting that it often isn't hard to work-around. - tye	[reply]
Re^4: Convincing Module::Install to put stuff in inc/ (zilla--) by chromatic (Archbishop) on May 26, 2012 at 18:58 UTC
I find dzil to be a huge help when I code, so much that the lack of dzil on some of my older CPAN modules makes me not want to work on them. With that said, I'm very sympathetic to the experience of trying to patch a dzil-using module; it can be a real hassle to reach that point. Would it help if the README or some piece of documentation somewhere (if not README, then what?) said that it's okay to use `prove` to run the tests, and that any patches can safely ignore dzil if you don't want to use it?	[reply] [d/l]
Re^5: Convincing Module::Install to put stuff in inc/ (zilla--) by tye (Sage) on May 27, 2012 at 00:27 UTC
Even better would be to include a Makefile or Makefile.PL that would support "make test" and would say something helpful for most other invocations. Patch such into Dist::Zilla so everybody can benefit. - tye	[reply]
Re^5: Convincing Module::Install to put stuff in inc/ (zilla--) by Oberon (Monk) on May 29, 2012 at 23:51 UTC
Would it help if the README or some piece of documentation somewhere (if not README, then what?) said that it's okay to use prove to run the tests, and that any patches can safely ignore dzil if you don't want to use it? Thinking further on this, if we could agree on the basic wording for such a blurb, someone could easily write a DZ plugin to have that deposited in your README automatically. :-D Not sure if this engenders a chicken-and-egg issue, but I bet it could be worked out.	[reply]