This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id:
75951
Status:
open
Priority:
Low/Low
Queue:

People
Owner:
Nobody in particular
Requestors:
dagolden [...] cpan.org
Cc:
AdminCc:

BugTracker
Severity:
Normal
Broken in:
(no value)
Fixed in:
(no value)



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.
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
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.
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
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?
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.
I agree with the original ticket here. M::B::Compat would work best as a separate distribution.
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?
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
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.


This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.