Bug #88642 for Dist-Zilla-PluginBundle-Author-ETHER: Please consider avoiding MBT altogether in your bundle

Fri Sep 13 01:21:14 2013 ribasushi [...] leporine.io - Ticket created

CC:	mst [...] shadowcat.co.uk
Subject:	Please consider avoiding MBT altogether in your bundle

Normally none of this would have been a problem, except the fact that you do many releases of modules sitting *very* low on the depchain. As such more and more of your releases will be very hard to install on a CPAN.pm that comes with say 5.8.8. Now you may (rightfully) say "the user can upgrade CPAN", except it would utterly break MVR testing as described here: https://github.com/dbsrgits/dbix-class/blob/master/maint/travis-ci_scripts/30_before_script.bash#L34 Ultimately it is your call how to proceed, but overall using MBT for toolchain-ish modules (like say anything that is needed to bootstrap Moo) is a massive step backwards. I hope you reconsider ;) Cheers

Fri Sep 13 13:07:00 2013 ether [...] cpan.org - Correspondence added

RT-Send-CC:

mst [...] shadowcat.co.uk

There is already an 'installer' option in the bundle that lets the dist select between MBT/MB/EUMM (or anything else!) for packaging, and has done so since version 0.007 (before it switched from EUMM to MBT as a default installer) so this isn't an issue with the bundle itself. The appropriate minimum bar for dists can be settled on a per-dist basis, so it wouldn't be appropriate to debate it here :)

Fri Sep 13 13:07:01 2013 The RT System itself - Status changed from 'new' to 'open'

Fri Sep 13 13:07:01 2013 ether [...] cpan.org - Status changed from 'open' to 'resolved'

Fri Sep 13 13:07:01 2013 ether [...] cpan.org - Fixed in 0.007 added

Fri Sep 13 13:33:24 2013 rt-cpan [...] trout.me.uk - Correspondence added

On Fri Sep 13 13:07:00 2013, ETHER wrote: Show quoted text

> There is already an 'installer' option in the bundle that lets the > dist select between MBT/MB/EUMM (or anything else!) for packaging, and > has done so since version 0.007 (before it switched from EUMM to MBT > as a default installer) so this isn't an issue with the bundle itself. > > The appropriate minimum bar for dists can be settled on a per-dist > basis, so it wouldn't be appropriate to debate it here :)

My POV: 17:28 <mst> for ... apps-level stuff, MBT seems like a definite good idea now 17:28 <mst> for lower level stuff, just let dzil handle generating EUMM and leave it be 17:28 <mst> dzil has to keep supporting that for things like CPAN::Meta anyway So leave the default in the PluginBundle as-is but for e.g. CMM change back to generating a Makefile.PL by setting the installer option.

Tue Sep 17 01:40:05 2013 ribasushi [...] leporine.io - Correspondence added

On Fri Sep 13 13:07:00 2013, ETHER wrote: Show quoted text

> > The appropriate minimum bar for dists can be settled on a per-dist > basis, so it wouldn't be appropriate to debate it here :)

Sorry in advance for reopening this ticket. Please read the whole reply before forming an opinion. I want to reply to the quoted part above only, as I believe my message was not fully understood. The problem (as I see it) is that Module::Build::Tiny (and Module::Build for that matter) is not appropriate for an overwhelming portion of the kinds of dists you are personally releasing these days. This is why the bug was filed against your personal bundle (which could perhaps be solved by an ...ETHER::Toolchain sub-bundle). In fact a distribution that comes with *only* a Build.PL is likely not properly installable on the stock CPAN.pm that comes with (drumroll) 5.8.8[1]. This is btw also the reason for the compat-makefile existence. Furthermore, while this is an inconvenience for a (agreably vanishingly small userbase), a default of MBT or MB is not bringing *you* any kind of benefit (I would really like you to correct me if I am wrong). This is why I believe this ticket belongs here, and not at the individual dist level. The mechanism you propose will result in us playing a catch-up on more and more bugs being filed on my side and being fixed and closed on your side. Let's automate this process away ;) [1] Grep for 'Package seems to come without Makefile.PL.' in https://s3.amazonaws.com/archive.travis-ci.org/jobs/11307690/log.txt, and read the scary text two lines after that one. [2] [2] Yes, I am aware there are other module in the same situation. The raison d'être of this ticket is to prevent substantially more modules turning the same way. Cheers

Tue Sep 17 01:40:06 2013 ribasushi [...] leporine.io - Status changed from 'resolved' to 'open'

Tue Sep 17 14:42:04 2013 LEONT [...] cpan.org - Correspondence added

On Tue Sep 17 01:40:05 2013, RIBASUSHI wrote: Show quoted text

> Sorry in advance for reopening this ticket. Please read the whole > reply before forming an opinion. I want to reply to the quoted part > above only, as I believe my message was not fully understood. The > problem (as I see it) is that Module::Build::Tiny (and Module::Build > for that matter) is not appropriate for an overwhelming portion of the > kinds of dists you are personally releasing these days. This is why > the bug was filed against your personal bundle (which could perhaps be > solved by an ...ETHER::Toolchain sub-bundle). > > In fact a distribution that comes with *only* a Build.PL is likely not > properly installable on the stock CPAN.pm that comes with (drumroll) > 5.8.8[1]. This is btw also the reason for the compat-makefile > existence. > > Furthermore, while this is an inconvenience for a (agreably > vanishingly small userbase), a default of MBT or MB is not bringing > *you* any kind of benefit (I would really like you to correct me if I > am wrong). > > This is why I believe this ticket belongs here, and not at the > individual dist level. The mechanism you propose will result in us > playing a catch-up on more and more bugs being filed on my side and > being fixed and closed on your side. Let's automate this process away > ;)

IMNSHO, this breaking for them is a feature, not a bug. They're a weight tied to our necks. If we want progress in our toolchain they will need to upgrade. If they really want to keep using an ancient version of perl that's fine by me, but they get to deal with their part of the consequences: they can easily solve it by typing «cpan CPAN». They can't have their cake and eat it. Show quoted text

> [1] Grep for 'Package seems to come without Makefile.PL.' in > https://s3.amazonaws.com/archive.travis-ci.org/jobs/11307690/log.txt, > and read the scary text two lines after that one. [2]

Funnily enough, an MBT distribution that doesn't have dependencies, scripts or XS components should actually install just fine that way AFAIK. Leon

Tue Sep 17 15:23:44 2013 ether [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #88642] Please consider avoiding MBT altogether in your bundle
Date:	Tue, 17 Sep 2013 12:23:30 -0700
To:	Leon Timmermans via RT <bug-Dist-Zilla-PluginBundle-Author-ETHER [...] rt.cpan.org>
From:	Karen Etheridge <ether [...] cpan.org>

On Tue, Sep 17, 2013 at 02:42:05PM -0400, Leon Timmermans via RT wrote: Show quoted text

> IMNSHO, this breaking for them is a feature, not a bug. They're a weight tied to our necks. If we want progress in our toolchain they will need to upgrade. If they really want to keep using an ancient version of perl that's fine by me, but they get to deal with their part of the consequences: they can easily solve it by typing «cpan CPAN». They can't have their cake and eat it.

I wonder if it would be useful to insert boilerplate code into Makefile.PL/Build.PL that said "hey, your CPAN client is too old. Upgrade it now or risk inconsistent results." if any of the major clients are older than a certain cutoff point. Show quoted text

> a default of MBT or MB is not bringing *you* any kind of benefit

Being able to avoid both EUMM and MB is a huge win in my books. MBT is *tiny* and does very little - if a dist doesn't need more features than what it provides, I see a huge gain in going tiny. I'm not sure what else there is for us to discuss. I already agreed to revert Module::Metadata back to EUMM.

Tue Sep 17 16:15:37 2013 LEONT [...] cpan.org - Correspondence added

On Tue Sep 17 15:23:44 2013, ETHER wrote: Show quoted text

> I wonder if it would be useful to insert boilerplate code into > Makefile.PL/Build.PL that said "hey, your CPAN client is too old. > Upgrade > it now or risk inconsistent results." if any of the major clients are > older > than a certain cutoff point.

I don't think there's a reliable way to detect which cpan client/version is running exactly and what its capabilities are (there are some environmental variables but they're a mess). Leon

Tue Sep 17 18:21:41 2013 haarg [...] haarg.org - Correspondence added

On Tue Sep 17 15:23:44 2013, ETHER wrote: Show quoted text

> Being able to avoid both EUMM and MB is a huge win in my books. MBT is > *tiny* and does very little - if a dist doesn't need more features > than > what it provides, I see a huge gain in going tiny.

Can you elaborate on what concrete gain it gives you? Given Dist::Zilla, you are never really interacting with the build tool directly.

Tue Sep 17 18:34:20 2013 ether [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #88642] Please consider avoiding MBT altogether in your bundle
Date:	Tue, 17 Sep 2013 15:34:07 -0700
To:	Graham Knop via RT <bug-Dist-Zilla-PluginBundle-Author-ETHER [...] rt.cpan.org>
From:	Karen Etheridge <ether [...] cpan.org>

On Tue, Sep 17, 2013 at 06:21:42PM -0400, Graham Knop via RT wrote: Show quoted text

> Can you elaborate on what concrete gain it gives you? Given Dist::Zilla, you are never really interacting with the build tool directly.

Essentially: I trust leont and the <100 lines of MBT code more than the legacy %@$@#$ in EUMM and MB. I know exactly what it will do and that it won't try to do more.

Wed Sep 18 12:15:18 2013 ether [...] cpan.org - Status changed from 'open' to 'resolved'

Fri Sep 20 11:45:04 2013 mst [...] shadowcat.co.uk - Correspondence added

CC:	ribasushi [...] cpan.org
Subject:	Re: [rt.cpan.org #88642] Please consider avoiding MBT altogether in your bundle
Date:	Fri, 20 Sep 2013 15:44:49 +0000
To:	Leon Timmermans via RT <bug-Dist-Zilla-PluginBundle-Author-ETHER [...] rt.cpan.org>
From:	Matt S Trout <mst [...] shadowcat.co.uk>

On Tue, Sep 17, 2013 at 04:15:38PM -0400, Leon Timmermans via RT wrote: Show quoted text

> I don't think there's a reliable way to detect which cpan client/version is running exactly and what its capabilities are (there are some environmental variables but they're a mess).

Sure there is. If it's old enough to be complete shit, it'll run Makefile.PL. So, what we do is - generate an MBT Build.PL and an EUMM Makefile.PL, and at the top of the Makefile.PL have - warn <<EOW *** WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING *** If you're seeing this warning, your toolchain is really, really old and you'll almost certainly have problems installing CPAN modules from this century. But never fear, dear user, for we have the technology to fix this! If you're using CPAN.pm to install things, then you can upgrade it using: cpan CPAN If you're using CPANPLUS to install things, then you can upgrade it using: cpanp CPANPLUS If you're using cpanminus, you shouldn't be seeing this message in the first place, so please file an issue on github. If you're installing manually, please retrain your fingers to run Build.PL when present instead. This public service announcement was brought to you by the Perl Toolchain Gang, the irc.perl.org #toolchain IRC channel, and the number 42. EOW sleep 10 if -t *STDIN; That should provide maximum odds of interactive users with ancient setups getting something better, while still letting non-interactive smoking work and ribasushi continue to indulge his gerontophilia fetish. -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN commercial support, training and consultancy packages could help your team.

Fri Sep 20 11:58:30 2013 ribasushi [...] leporine.io - Correspondence added

CC:	Leon Timmermans via RT <bug-Dist-Zilla-PluginBundle-Author-ETHER [...] rt.cpan.org>
Subject:	Re: [rt.cpan.org #88642] Please consider avoiding MBT altogether in your bundle
Date:	Fri, 20 Sep 2013 15:58:15 +0000
To:	Matt S Trout <mst [...] shadowcat.co.uk>
From:	Peter Rabbitson <ribasushi [...] cpan.org>

On Fri, Sep 20, 2013 at 03:44:49PM +0000, Matt S Trout wrote: Show quoted text

> > That should provide maximum odds of interactive users with ancient setups > getting something better, while still letting non-interactive smoking work > and ribasushi continue to indulge his gerontophilia fetish. >

My name is Peter Rabbitson and I approve this message.

Fri Sep 20 12:03:02 2013 ether [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #88642] Please consider avoiding MBT altogether in your bundle
Date:	Fri, 20 Sep 2013 09:02:48 -0700
To:	Matt S Trout via RT <bug-Dist-Zilla-PluginBundle-Author-ETHER [...] rt.cpan.org>
From:	Karen Etheridge <ether [...] cpan.org>

On Fri, Sep 20, 2013 at 11:45:04AM -0400, Matt S Trout via RT wrote: Show quoted text

> That should provide maximum odds of interactive users with ancient setups > getting something better, while still letting non-interactive smoking work > and ribasushi continue to indulge his gerontophilia fetish.

If I can figure out a way of not displaying this warning every time we do a 'dzil test', I'll be switching my bundle to using MakeMaker-with-warning *and* ModuleBuildTiny by default. This is a sane compromise that seems to give everyone what they want. mst++

Fri Sep 20 13:57:31 2013 ether [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #88642] Please consider avoiding MBT altogether in your bundle
Date:	Fri, 20 Sep 2013 10:57:16 -0700
To:	Peter Rabbitson via RT <bug-Dist-Zilla-PluginBundle-Author-ETHER [...] rt.cpan.org>
From:	Karen Etheridge <ether [...] cpan.org>

On Fri, Sep 20, 2013 at 11:58:30AM -0400, Peter Rabbitson via RT wrote: Show quoted text

> On Fri, Sep 20, 2013 at 03:44:49PM +0000, Matt S Trout wrote:

> > > > That should provide maximum odds of interactive users with ancient setups > > getting something better, while still letting non-interactive smoking work > > and ribasushi continue to indulge his gerontophilia fetish. > >

> > My name is Peter Rabbitson and I approve this message.

The end of the world must be nigh, if the three of us are agreeing about something.

Sat Sep 21 04:18:21 2013 ribasushi [...] leporine.io - Correspondence added

On Fri Sep 20 12:03:02 2013, ETHER wrote: Show quoted text

> On Fri, Sep 20, 2013 at 11:45:04AM -0400, Matt S Trout via RT wrote:

> > That should provide maximum odds of interactive users with ancient setups > > getting something better, while still letting non-interactive smoking work > > and ribasushi continue to indulge his gerontophilia fetish.

> > If I can figure out a way of not displaying this warning every time we do a > 'dzil test'

Why would `dzil test` invoke the Makefile.PL when a Build.PL is present...? I may be missing something wrt how dzil test operates...

Sat Sep 21 13:17:05 2013 ether [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #88642] Please consider avoiding MBT altogether in your bundle
Date:	Sat, 21 Sep 2013 10:16:49 -0700
To:	Peter Rabbitson via RT <bug-Dist-Zilla-PluginBundle-Author-ETHER [...] rt.cpan.org>
From:	Karen Etheridge <ether [...] cpan.org>

On Sat, Sep 21, 2013 at 04:18:22AM -0400, Peter Rabbitson via RT wrote: Show quoted text

> Why would `dzil test` invoke the Makefile.PL when a Build.PL is present...? I may be missing something wrt how dzil test operates...

It doesn't look at what files are available -- it invokes the 'test' method on all plugins that use the InstallTool role.

Mon Sep 23 20:30:25 2013 ether [...] cpan.org - Correspondence added

For those following along at home, this weekend I released http://metacpan.org/module/Dist::Zilla::Plugin::MakeMaker::Fallback, and my pluginbundle (version 0.025) now uses it in combination with [ModuleBuildTiny] by default when the 'installer' config is not set.