Skip Menu |

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

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

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

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



Subject: Deprecate passthrough Makefile.PL
With the introduction of configure_requires to CPAN/CPANPLUS, the need for the passthrough Makefile.PL is gone. Deprecating and then removing Module::Build::Compat (or at least the passthrough/small forms of it) will significantly reduce a maintenance burden for Module::Build. Module::Build should deprecate and warn when these are used and support should be removed in a future version.
On Thu Aug 20 12:00:40 2009, DAGOLDEN wrote: Show quoted text
> With the introduction of configure_requires to CPAN/CPANPLUS, the need > for the passthrough Makefile.PL is gone.
I think that's putting it too strongly. There are still processes out there that depend on there being a Makefile.PL. I do support deprecating it though.
Subject: Re: [rt.cpan.org #48884] Deprecate passthrough Makefile.PL
Date: Thu, 20 Aug 2009 12:09:50 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Ken Williams via RT wrote: Show quoted text
> Queue: Module-Build > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=48884 > > > On Thu Aug 20 12:00:40 2009, DAGOLDEN wrote:
>> With the introduction of configure_requires to CPAN/CPANPLUS, the need >> for the passthrough Makefile.PL is gone.
> > I think that's putting it too strongly. There are still processes out > there that depend on there being a Makefile.PL. > > I do support deprecating it though.
David is only advocating eliminating the "passthrough" option which tries to install Module::Build and then does a "small" style Makefile.PL. The passthrough part is self-contained in the Makefile.PL so removing it from Module::Build::Compat will have no effect on existing distributions. Authors currently using passthrough will have to change to small or traditional before making a new release. That's acceptable. -- Stabbing you in the face for your own good.
Actually, in the long-run, I'd like to see "small" removed as well. In the short run, marking passthrough and small as deprecated and issuing liberal warnings when Makefile.PL is generated should be sufficient and the removal can be a year down the road. Bigger picture, even longer-term, I'd like to see M::B::Compat as a whole deprecated and then go away as it's a huge maintenance time-suck. Now that EU::MM is adding features again (CONFIGURE_REQUIRES, BUILD_REQUIRES), I'm sure people will start clamoring for M::B::Compat to support them even in 'traditional' Makefile.PL generation. And that's just not where I see any of the active maintainers wanting to spend time. -- David
Patched in trunk. Only 'passthrough' is marked deprecated, as 'small' could still have valid uses and 'configure_requires' is sufficient to support 'small' style. I'm sure we won't actually remove 'passthrough' for years, but we can start nudging people away from it now. -- David
Subject: Re: [rt.cpan.org #48884] Deprecate passthrough Makefile.PL
Date: Mon, 31 Aug 2009 14:31:06 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
David Golden via RT wrote: Show quoted text
> I'm sure we won't actually remove 'passthrough' for years, but we can > start nudging people away from it now.
What's the logic behind not removing it? Only authors making dists are effected, not installations. -- Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Subject: Re: [rt.cpan.org #48884] Deprecate passthrough Makefile.PL
Date: Mon, 31 Aug 2009 16:48:44 -0500
To: bug-Module-Build [...] rt.cpan.org
From: Ken Williams <kwilliams [...] cpan.org>
On Mon, Aug 31, 2009 at 4:31 PM, Michael G Schwern via RT<bug-Module- Show quoted text
> David Golden via RT wrote:
>> I'm sure we won't actually remove 'passthrough' for years, but we can >> start nudging people away from it now.
> > What's the logic behind not removing it?  Only authors making dists are > effected, not installations.
It's still pulling the rug out from under those authors that use it. It seems couth to give them some notice. It's also part of toolchains for module packagers. Both are groups of people I don't want to annoy. -Ken
Subject: Re: [rt.cpan.org #48884] Deprecate passthrough Makefile.PL
Date: Mon, 31 Aug 2009 15:15:39 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Ken Williams via RT wrote: Show quoted text
> Queue: Module-Build > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=48884 > > > On Mon, Aug 31, 2009 at 4:31 PM, Michael G Schwern via RT<bug-Module-
>> David Golden via RT wrote:
>>> I'm sure we won't actually remove 'passthrough' for years, but we can >>> start nudging people away from it now.
>> What's the logic behind not removing it? Only authors making dists are >> effected, not installations.
> > It's still pulling the rug out from under those authors that use it. > It seems couth to give them some notice.
Years though? How about months? Its not like removing passthrough causes a dire problem. MB::Compat sees "passthrough" and issues an error telling the author to change to "small". The author s/passthrough/small/ and everything works just as before. Hell, we can just change passthrough to issue a warning and do a small. Show quoted text
> It's also part of toolchains > for module packagers. Both are groups of people I don't want to > annoy.
Module packagers... like rpms? Why are they building their own passthrough Makefile.PLs? -- If you want the truth to stand clear before you, never be for or against. The struggle between "for" and "against" is the mind's worst disease. -- Sent-ts'an
Subject: Re: [rt.cpan.org #48884] Deprecate passthrough Makefile.PL
Date: Mon, 31 Aug 2009 17:27:28 -0500
To: bug-Module-Build [...] rt.cpan.org
From: Ken Williams <kwilliams [...] cpan.org>
On Mon, Aug 31, 2009 at 5:16 PM, Michael G Schwern via RT<bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> > Years though?  How about months?
Sure, months is fine. Show quoted text
>> It's also part of toolchains >> for module packagers.  Both are groups of people I don't want to >> annoy.
> > Module packagers... like rpms?  Why are they building their own passthrough > Makefile.PLs?
Hmm. Yeah, I guess they're not. I think the only reason they'll care is that this is another nail in the coffin of Makefile.PL (sometimes a 'traditional' Makefile.PL just isn't appropriate, e.g. if you're using some of the advanced M::B features) and some people rely on there always being a Makefile.PL around. Yet another reason to fire a deprecation warning across their bows. -Ken
Subject: Re: [rt.cpan.org #48884] Deprecate passthrough Makefile.PL
Date: Mon, 31 Aug 2009 19:11:04 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
On Mon, Aug 31, 2009 at 6:16 PM, Michael G Schwern via RT<bug-Module->> It's still pulling the rug out from under those authors that use it. Show quoted text
>> It seems couth to give them some notice.
> > Years though?  How about months? > > Its not like removing passthrough causes a dire problem.  MB::Compat sees > "passthrough" and issues an error telling the author to change to "small". > The author s/passthrough/small/ and everything works just as before. > > Hell, we can just change passthrough to issue a warning and do a small.
Let me weigh in with my thoughts. If 'configure_requires' were widely supported, we could just default people to 'small'. But it's only now in core and there will undoubtedly be people that complain that their 5.6/5.8 perl can't possibly upgrade CPAN *once* to forever have configure_requires support. Given that, there may still be authors that *like* that there is a 'passthrough' option that installs Module::Build as it's more backwards compatible than relying on 'configure_requires'. Removing it means they can't upgrade Module::Build and release upgrades of a distro that previously had a passthrough Makefile.PL without a lot of work. What would be "nice to authors" would be to replace passthrough with M::B bundled in inc/ the way that Module::Install does it. If we get that working with no more bugs than passthrough has now, then we can yank passthrough and offer inc bundling in its place as the 'backwards compatible' option. Show quoted text
>> It's also part of toolchains >> for module packagers.  Both are groups of people I don't want to >> annoy.
> > Module packagers... like rpms?  Why are they building their own passthrough > Makefile.PLs?
Some of the linux packagers have Makefile.PL/make based packaging tools. So authors wanting to make their stuff as package friendly as possible would want to offer Makefile.PL. I don't like it, but that's the way it is. All that said, I'm OK seeing it removed "soon". My crack about "years" is more a play on the usual Perl backwards compatible deprecation/removal cycle. -- David
Subject: Re: [rt.cpan.org #48884] Deprecate passthrough Makefile.PL
Date: Tue, 01 Sep 2009 12:08:19 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
Ken Williams via RT wrote: Show quoted text
> Hmm. Yeah, I guess they're not. I think the only reason they'll care > is that this is another nail in the coffin of Makefile.PL (sometimes a > 'traditional' Makefile.PL just isn't appropriate, e.g. if you're using > some of the advanced M::B features) and some people rely on there > always being a Makefile.PL around. Yet another reason to fire a > deprecation warning across their bows.
There's enough Build.PL only modules on CPAN now that anyone serious can't ignore it, I've made sure of that. :) -- 29. The Irish MPs are not after "Me frosted lucky charms". -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
Subject: Re: [rt.cpan.org #48884] Deprecate passthrough Makefile.PL
Date: Tue, 01 Sep 2009 13:13:30 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
David Golden via RT wrote: Show quoted text
> Let me weigh in with my thoughts. If 'configure_requires' were widely > supported, we could just default people to 'small'. But it's only now > in core and there will undoubtedly be people that complain that their > 5.6/5.8 perl can't possibly upgrade CPAN *once* to forever have > configure_requires support. > > Given that, there may still be authors that *like* that there is a > 'passthrough' option that installs Module::Build as it's more > backwards compatible than relying on 'configure_requires'. Removing > it means they can't upgrade Module::Build and release upgrades of a > distro that previously had a passthrough Makefile.PL without a lot of > work. > > What would be "nice to authors" would be to replace passthrough with > M::B bundled in inc/ the way that Module::Install does it. If we get > that working with no more bugs than passthrough has now, then we can > yank passthrough and offer inc bundling in its place as the 'backwards > compatible' option.
Deprecating something means you plan to remove it and there's something better to replace it. It doesn't sound like you're ready to remove it. There's a not a replacement for your use cases and so is not ready to be removed. In that case don't deprecate it until the inc/ stuff is working. And yes, getting the inc/ and latest.pm stuff working would solve a lot of problems. +1 to that. Show quoted text
>> Module packagers... like rpms? Why are they building their own passthrough >> Makefile.PLs?
> > Some of the linux packagers have Makefile.PL/make based packaging > tools. So authors wanting to make their stuff as package friendly as > possible would want to offer Makefile.PL. I don't like it, but that's > the way it is.
That is orthogonal. "small" and "traditional" cover this hole just as well as "passthrough". The packager doesn't generate that Makefile.PL, the author does. -- 39. Not allowed to ask for the day off due to religious purposes, on the basis that the world is going to end, more than once. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
The deprecation message has been added and now we're arguing about when/how to remove the feature. I've changed the subject to match and marked it "wishlist". Yes, we'll do it eventually, but I want to get it off the list of "normal" issues that I use to triage my round tuits. David