|
in reply to Convincing Module::Install to put stuff in inc/
(Yes, yes, I really should upgrade it to Dist::Zilla, but I don't have time right now. I will soon, honest!)
Well, that will certainly prevent several people from contributing to that module. It provides a huge barrier to even writing a patch for your module. And not being able to write a patch can even discourage just reporting a bug. (Though, some of that last part is mostly repeating what brian d foy said the other day.)
I had a one-line change to a module that I desperately wanted deployed and really, really wanted uploaded to CPAN. But Dist::Zilla is way too much work and that was very effective at preventing me from getting to either of those tasks, that would otherwise be quick work.
|
Re^2: Convincing Module::Install to put stuff in inc/ (zilla--)
by tobyink (Canon) on May 26, 2012 at 10:32 UTC
|
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'
| [reply]
[d/l]
[select] |
|
|
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.
| [reply] |
|
|
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^2: Convincing Module::Install to put stuff in inc/ (zilla--)
by Oberon (Monk) on May 27, 2012 at 09:49 UTC
|
Ah, someone who actually doesn't like DZ ... I sorta thought it was the latest Perl darling, at least in the distro packaging arena. But I suppose there's always a contrary viewpoint.
I gotta be honest: I always felt DZ was overkill myself, and I never planned on really checking it out until I was juggling like a dozen CPAN modules at once (if I ever get there). But then I got handed a project to come up with a packaging system for $work, and even then I was going to stay away from DZ--I was tentatively planning on using a combination of ExtUtils::ModuleMaker and Module::Install--but the more I started looking at what I needed to do, the more I realized that, FTMP, DZ already did it, and so I ended up biting the bullet. Now I can't imagine doing without it.
Of course, as I say, I still haven't converted any of my modules over to use it ... it's not particularly conducive to just jumping in and getting started quickly (at least IME). But I do plan on doing so eventually. I think in the long run I'll be happier: less whining about having to keep version numbers sync'ed across multiple library files, less maintaining of my own cobbled together script for PAUSE uploads, less boilerplate copying, etc. And I think tobyink has the right of it in terms of potential contributors running tests: prove is the bomb. I use that over make test myself, most of the time.
And, of course, there's also the concept that, the more popular it becomes, the less you can avoid it. I never particularly liked Module::Build (e.g.), and in fact I spent a few months cursing its name in the early days, but there's no point trying to pretend it doesn't exist at this point: you have to learn to deal with it, that's all.
Maybe DZ will never reach that point though. Who can say?
| [reply]
[d/l]
[select] |
|
|
"less whining about having to keep version numbers sync'ed across multiple library files"
Seen perl-reversion which comes with the Perl::Version module? It makes this a breeze. (In fact, DZ uses Perl::Version to do its version-setting dirty work, so if you've got DZ on your system, you've already got perl-reversion installed!)
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'
| [reply] |
|
|
| [reply] |
|
|
But I do plan on doing so eventually. I think in the long run I'll be happier: less whining about having to keep version numbers sync'ed across multiple library files, less maintaining of my own cobbled together script for PAUSE uploads, less boilerplate copying, etc.
It sounds more like you are doing it wrong, to me. I see no point in putting the same version number into multiple library files. You don't have to use your own upload script. You can just use CPAN::Uploader which is easy to just jump right into.
I have quite a few modules on CPAN and more not there yet and I don't have anything that I consider "boiler plate". I do sometimes copy an old module when making a new module but that's one short command and just done to get the structure and then to replace 99% of it. And trying to abstract out the common skeleton would be a waste of time because it keeps evolving and there are always parts that fit some modules and not others.
So you haven't hit on a reason why I would benefit from using Dist::Zilla. But it'd have to be a pretty powerful benefit for me to invest the time to get half of CPAN installed and risk having such a huge amount of complexity behind something such that I might have to dive into that much stuff to try to diagnose when something goes wrong.
| [reply] |
|
|
I see no point in putting the same version number into multiple library files.
I have at least two distros (which is, like, 50% of my total distros <g>) where, every time I bump the version, I have 3 places to change the version number: the Changes file, the main .pm module, and a subsidiary .pm module. And, even in the other two, there's still two places to change it. It's a little thing, but it's irksome when they get out of sync, and isn't that what computers are supposed to do? automate the little, repetitive things?
You don't have to use your own upload script. You can just use CPAN::Uploader which is easy to just jump right into.
Yep, my script calls CPAN::Uploader. It also makes sure I remembered to sync my version numbers (at least between Changes and the main module), makes sure I remembered to update Changes at all, does a make disttest for me, commits and tags the code, etc. Basically, it does all the things that DZ does, only I have to maintain it, as opposed to RJBS doing it. ;->
I have quite a few modules on CPAN and more not there yet and I don't have anything that I consider "boiler plate".
No? not even the license sections? What about the support sections? Do you use a version section (there's another place to sync that version number ...)? At least the author section would be the same on all of them ...
So you haven't hit on a reason why I would benefit from using Dist::Zilla.
Fair enough. Far be it from me to attempt to be a Dist::Zilla evangelist. :-D Like anything in Perl, TMTOWTDI, and DZ will work for some and not for others. IIRC, it was Voltaire who said there are Perl modules which are not for all men, nor for all times. ;->
But I shan't be surprised if, given 10 years, as Anon notes above, DZ will be some sort of standard in distros. And I won't be upset about it, really. (Of course, I wouldn't be upset if it isn't either. I'm easy that way. <shrug>
| [reply]
[d/l]
[select] |
|
|
Ah, someone who actually doesn't like DZ ... I sorta thought it was the latest Perl darling, at least in the distro packaging arena. But I suppose there's always a contrary viewpoint.
That number is quite larger than you might believe :) Why I hate Dist::Zilla was only posted last year. Give it another 10 years and dzil will be as popular as Module::Build ;p
| [reply] |
|
|
Why I hate Dist::Zilla was only posted last year.
Yep. I've read that before. But that was all about difficulty installing DZ, which I don't think is a problem these days (certainly I haven't had any problems installing it). Rereading it quickly confirms my recollection: it doesn't say anything negative about using DZ at all.
Give it another 10 years and dzil will be as popular as Module::Build ;p
Yes, and all that that implies. ;->
| [reply] |
|
|
|
|
