in reply to Re: Convincing Module::Install to put stuff in inc/ (zilla--)
in thread Convincing Module::Install to put stuff in inc/

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?

Replies are listed 'Best First'.
Re^3: Convincing Module::Install to put stuff in inc/ (zilla--)
by tobyink (Canon) on May 27, 2012 at 18:21 UTC

    "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'
      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!)

      Ah, another good tip! I'll see if I can use this in my CPAN release script as a stopgap measure until I get around to investigating DZ more thoroughly. Thanx again!

Re^3: Convincing Module::Install to put stuff in inc/ (no zilla++)
by tye (Sage) on May 27, 2012 at 16:29 UTC
    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.

    - tye        

      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>

Re^3: Convincing Module::Install to put stuff in inc/ (zilla--)
by Anonymous Monk on May 27, 2012 at 10:13 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.

    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

      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. ;->

        The author of that node (and all of the people who worked with him on the modules that he set Dist::Zilla upon) eventually did decide that using Dist::Zilla was serious enough of a mistake that they were (all) enthusiastic to get rid of Dist::Zilla (but weren't sure exactly how best to do that).

        - tye