Bug #75951 for Module-Build: Module::Build::Compat should be deprecated and/or split out

Wed Mar 21 16:04:40 2012 dagolden [...] cpan.org - Ticket created

Subject:

Module::Build::Compat should be deprecated and/or split out

M::B::Compat isn't fully compatible and it's unrealistic (at current volunteer support levels) to maintain compatibility as EU::MM itself continues to evolve. I suggest deprecating M::B::Compat and splitting it out as a separate CPAN module "soon". Generating a compatibility Makefile.PL should warn about the deprecation unless the split-out M::B::Compat (with a high enough version) is installed. Once removed from Module::Build, if M::B::Compat is not available, trying to build a compatibility Makefile.PL should die with a message to install it from CPAN.

Thu Mar 22 07:48:20 2012 LEONT [...] cpan.org - Correspondence added

On Wed Mar 21 16:04:40 2012, DAGOLDEN wrote: Show quoted text

> M::B::Compat isn't fully compatible and it's unrealistic (at current > volunteer support levels) to maintain compatibility as EU::MM itself > continues to evolve. > > I suggest deprecating M::B::Compat and splitting it out as a separate > CPAN module "soon". Generating a compatibility Makefile.PL should warn > about the deprecation unless the split-out M::B::Compat (with a high > enough version) is installed. > > Once removed from Module::Build, if M::B::Compat is not available, > trying to build a compatibility Makefile.PL should die with a message to > install it from CPAN.

I don't think we can really split it out: it would break too much for too many people. Leon

Thu Mar 22 07:48:21 2012 The RT System itself - Status changed from 'new' to 'open'

Thu Mar 22 11:22:59 2012 dagolden [...] cpan.org - Correspondence added

It could be managed via a configure/requires prereq, I think. Even if it's a long-term deprecation cycle, I think it will be worth it in the end.

Wed Aug 29 12:06:00 2012 LEONT [...] cpan.org - Correspondence added

On Thu Mar 22 11:22:59 2012, DAGOLDEN wrote: Show quoted text

> It could be managed via a configure/requires prereq, I think. > > Even if it's a long-term deprecation cycle, I think it will be worth it > in the end.

It would break Makefile.PL compatibility for all modules using the passthrough or small compatibility option, which totals at about 700 of them. Leon

Sun May 05 03:18:05 2013 ANDK [...] cpan.org - Correspondence added

I agree that deprecation is too much work for too many people. I'd suggest documentation fixes instead. Documentation fixes that lead people on the right track, especially new users. Because NOT deprecating also has a price. What's the right term for this? Pulling features out without deprecating them? Discouraging? For example I find this paragraph in Compat.pm for create_makefile_pl/small: A small F<Makefile.PL> will be created that passes all functionality through to the F<Build.PL> script in the same directory. The user must already have C<Module::Build> installed in order to use this, or else they'll get a module-not-found error. I'm missing a sentence that tells the user that this is a misfeature that makes no sense at all. This would guide future generations through the hoops of Module::Build misfeatures and reduce the use of useless undersupported doubtful inventions. WDYT?

Thu May 30 00:34:29 2013 kwilliams [...] cpan.org - Correspondence added

On Sun May 05 03:18:05 2013, ANDK wrote: Show quoted text

> A small F<Makefile.PL> will be created that passes all functionality > through to the F<Build.PL> script in the same directory. The user > must > already have C<Module::Build> installed in order to use this, or else > they'll get a module-not-found error. > > I'm missing a sentence that tells the user that this is a misfeature > that makes no sense at all.

I'm surprised you say so. Much of the world found this helpful as a way to get CPAN.pm to install a Module::Build based distribution before CPAN.pm officially supported Module::Build. It really did work, you know. At this point though, with M::B support solid in the major CPAN clients, I agree this could be deprecated & removed now.

Thu May 30 00:35:54 2013 kwilliams [...] cpan.org - Correspondence added

I agree with the original ticket here. M::B::Compat would work best as a separate distribution.

Thu May 30 00:38:40 2013 kwilliams [...] cpan.org - Correspondence added

On Wed Aug 29 12:06:00 2012, LEONT wrote: Show quoted text

> > It would break Makefile.PL compatibility for all modules using the > passthrough or small compatibility option, which totals at about 700 of > them.

What would be the problem? If M::B::Compat is installed from a separate package or as part of the M::B package, how would a Makefile.PL ever even know the difference?

Thu May 30 06:55:58 2013 LEONT [...] cpan.org - Correspondence added

Subject:	Re: [rt.cpan.org #75951] Module::Build::Compat should be deprecated and/or split out
Date:	Thu, 30 May 2013 12:55:19 +0200
To:	bug-Module-Build [...] rt.cpan.org
From:	Leon Timmermans <leont [...] cpan.org>

On Thu, May 30, 2013 at 6:38 AM, Ken Williams via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text

>> It would break Makefile.PL compatibility for all modules using the >> passthrough or small compatibility option, which totals at about 700 of >> them.

> > What would be the problem? If M::B::Compat is installed from a separate package or as part of the M::B package, how would a Makefile.PL ever even know the difference?

Absolutely no one is declaring their dependency on M::B::Compat, only on M::B itself. So if it doesn't ship with M::B anymore, it will suddenly blow up in their face when it's no longer there… Leon

Thu May 30 23:00:50 2013 kwilliams [...] cpan.org - Correspondence added

On Thu May 30 06:55:58 2013, LEONT wrote: Show quoted text

> > Absolutely no one is declaring their dependency on M::B::Compat, only > on M::B itself. So if it doesn't ship with M::B anymore, it will > suddenly blow up in their face when it's no longer there…

I see - that's a tricky one, because most distributions that use M::B::Compat don't really *need* it during installation, they also have a Build.PL that can be used instead. There's no 'configure_may_use' declaration, it doesn't really match 'configure_requires', so the declaration doesn't happen. If Compat is just truly needed by nobody anymore, maybe plain-old deprecating & removing it - and splitting it out if anyone wants to - is the right way to go.