Skip Menu |
 

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

Report information
The Basics
Id: 75951
Status: open
Priority: 0/
Queue: Module-Build

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

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: Module::Build::Compat should be deprecated and/or split out
Download (untitled) / with headers
text/plain 564b
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.
Download (untitled) / with headers
text/plain 726b
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
Download (untitled) / with headers
text/plain 147b
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.
Download (untitled) / with headers
text/plain 351b
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
Download (untitled) / with headers
text/plain 904b
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?
Download (untitled) / with headers
text/plain 752b
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.
Download (untitled) / with headers
text/plain 363b
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>
Download (untitled) / with headers
text/plain 619b
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
Download (untitled) / with headers
text/plain 707b
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 is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

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