RFC: Deprecating Module::Build

[David Golden]

I propose deprecating Module::Build from core in 5.19 and removing it in 5.21.

My rationale:

* Module::Build has been in life-support maintainance for a couple
years now (thank you leont for taking up that awful task)

* CPAN clients have supported configure_requires to bootstrap a build
tool since Perl 5.10.1 almost a decade ago

* CPAN.pm has support for auto-detecting an undeclared dependency on
Module::Build and installing it when needed [1]

While many people still use M::B for their modules, it does not need
to be in core for CPAN modules to depend on it. Module::Build can be
removed from core and CPAN clients will install it on demand.

Given that it is buggy, complex and nearly unmaintained, I don't think
the core should implicitly be promising support for it. The fewer
modules in core, the less work for core maintainers.

(Personally, I hope the development of a Build.PL specification [2]
will encourage new, better successors anyway.)

If you disagree, now is the time to speak up. Ideally, if you care
enough about keeping Module::Build in core, you'll also volunteer to
take over active maintenance for it, right? :-)

David

[1] detection of undeclared M::B dependency was buggy, which implies
it hasn't been an issue in years anyway. I've sent a pull request to
fix it just in case.

[2] https://github.com/Perl-Toolchain-Gang/cpan-api-buildpl

--
David Golden <x...@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

[Carl Friedberg]

++

Carl Friedberg
www.esb.com
The Elias Book of Baseball Records
2013 Edition

[H.Merijn Brand]

On Wed, 22 May 2013 13:44:38 -0400, David Golden <x...@xdg.me> wrote:

> I propose deprecating Module::Build from core in 5.19 and removing it in 5.21.

++ from me

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

[Johan Vromans]

David Golden <x...@xdg.me> writes:

> * CPAN clients have supported configure_requires to bootstrap a build
> tool since Perl 5.10.1 almost a decade ago

Perl 5.10.1 was released August 22, 2009, less than 4 years ago.

Apart from this: No problem removing M::B from the core.

-- Johan

[Kent Fredric]

I think its reasonably fair to say, that either you have
A) A perl with module build ( 5.9.4 -> 5.18 )
or
B) A perl with proper configure_requires  ( 5.10.1 ->
or
C) A really archaic perl ( <5.9.4 )

So this change occuring in a *new* perl shouldn't create any new problems

And any perls that this /would/ be a problem on ( <5.9.4 ) , it is *already* a problem there if you have either

A) Not already installed Module::Build

or

B) Not already installed a CPAN client that supports configure_requires


--
Kent

[David Golden]

On Wed, May 22, 2013 at 5:34 PM, Johan Vromans <jvro...@squirrel.nl> wrote:
> David Golden <x...@xdg.me> writes:
>
>> * CPAN clients have supported configure_requires to bootstrap a build
>> tool since Perl 5.10.1 almost a decade ago
>
> Perl 5.10.1 was released August 22, 2009, less than 4 years ago.

Right. My bad. Still... it's way out of the support window.

[Leon Timmermans]

On Wed, May 22, 2013 at 7:44 PM, David Golden <x...@xdg.me> wrote:
> I propose deprecating Module::Build from core in 5.19 and removing it in 5.21.
>
> My rationale:
>
> * Module::Build has been in life-support maintainance for a couple
> years now (thank you leont for taking up that awful task)
>
> * CPAN clients have supported configure_requires to bootstrap a build
> tool since Perl 5.10.1 almost a decade ago
>
> * CPAN.pm has support for auto-detecting an undeclared dependency on
> Module::Build and installing it when needed [1]
>
> While many people still use M::B for their modules, it does not need
> to be in core for CPAN modules to depend on it. Module::Build can be
> removed from core and CPAN clients will install it on demand.

I'm generally in favor of getting stuff out of core. There is no
technical requirement anymore to have this in core.

Assuming about 15% of CPAN uses Module::Build, you'd install it after
on average 4.2 modules, I'm not sure that's an argument for or against
removing from core.

> Given that it is buggy, complex and nearly unmaintained, I don't think
> the core should implicitly be promising support for it. The fewer
> modules in core, the less work for core maintainers.

I've already chainsawed some modules out of Module::Build, removing it
from core would make it much easier to refactor Module::Build to use
them (as they wouldn't have to enter core).

It would likely also mean removing ExtUtils::CBuilder, which is even
less maintained and buggier than Module Build.

Likewise, Perl::OSType and possibly Module::Metadata could be removed.
This will likely have less of an impact though.

> (Personally, I hope the development of a Build.PL specification [2]
> will encourage new, better successors anyway.)

Working on that!

> If you disagree, now is the time to speak up. Ideally, if you care
> enough about keeping Module::Build in core, you'll also volunteer to
> take over active maintenance for it, right? :-)

Yeah, that'd be most welcome!

Leon

[David Golden]

On Thu, May 23, 2013 at 11:15 AM, Leon Timmermans <faw...@gmail.com> wrote:
> It would likely also mean removing ExtUtils::CBuilder, which is even
> less maintained and buggier than Module Build.

+1

> Likewise, Perl::OSType and possibly Module::Metadata could be removed.
> This will likely have less of an impact though.

Leaving aside my personal investment in the former, I think having
some OS "family" information maintained centrally could still have
some value. But I don't feels strongly about keeping it or
deprecating it.

If EU::MM isn't using Module::Metadata already, I hope that we might
get it to eventually. I'd like to have just *one* tool for toolchain
to use to parse stuff out of .pm files. I'd suggest not deprecating
it yet.

David

[Paul LeoNerd Evans]

On Wed, 22 May 2013 13:44:38 -0400

David Golden <x...@xdg.me> wrote:

> I propose deprecating Module::Build from core in 5.19 and removing it
> in 5.21.

Just one small question:

If it isn't core, does it still build OK from CPAN using whatever build
systems remain in core? Or does it suffer any bootstrapping issues?

--
Paul "LeoNerd" Evans

leo...@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/

[Leon Timmermans]

On Thu, May 23, 2013 at 7:36 PM, Paul LeoNerd <leo...@leonerd.org.uk> wrote:
>> I propose deprecating Module::Build from core in 5.19 and removing it
>> in 5.21.
>
> Just one small question:
>
> If it isn't core, does it still build OK from CPAN using whatever build
> systems remain in core? Or does it suffer any bootstrapping issues?

It already has to be capable of bootstrapping from 5.8, so yes that's
already covered. All its dependencies use ExtUtils::MakeMaker.

Leon

[Aristotle Pagaltzis]

* David Golden <x...@xdg.me> [2013-05-23 18:00]:

> If EU::MM isn't using Module::Metadata already, I hope that we might
> get it to eventually. I'd like to have just *one* tool for toolchain
> to use to parse stuff out of .pm files. I'd suggest not deprecating
> it yet.

If for no other reason than the Module::CoreList data model having no
way to express modules getting added back to the core after having
previously been removed? :-)

[Leon Timmermans]

On Thu, May 23, 2013 at 5:56 PM, David Golden <x...@xdg.me> wrote:
>> Likewise, Perl::OSType and possibly Module::Metadata could be removed.
>> This will likely have less of an impact though.
>
> Leaving aside my personal investment in the former, I think having
> some OS "family" information maintained centrally could still have
> some value. But I don't feels strongly about keeping it or
> deprecating it.

It's very low-maintenance anyway.

> If EU::MM isn't using Module::Metadata already, I hope that we might
> get it to eventually. I'd like to have just *one* tool for toolchain
> to use to parse stuff out of .pm files. I'd suggest not deprecating
> it yet.

Yeah, that would probably be a good thing.

Leon

[Paul LeoNerd Evans]

On Thu, 23 May 2013 19:38:33 +0200
Leon Timmermans <faw...@gmail.com> wrote:

> All its dependencies use ExtUtils::MakeMaker.

Ahh.. Yes; that part starts to feel tricky now.

Does the whole of its dependency tree know quite clearly that it cannot
use M::B at all then? Is this something that can somehow be enforced,
or at least smoke-tested on?

Dependency-creep happens, sometimes in nonobvious ways, that lead to
cyclic dependencies or other weird breakages - any non-core build
system feels like it could be much more prone to gaining one of these
by accident.

[Aristotle Pagaltzis]

* Paul LeoNerd Evans <leo...@leonerd.org.uk> [2013-05-23 23:20]:

> Is this something that can somehow be enforced, or at least
> smoke-tested on?

Anyone running a CPAN smoker under a pre-M::B perl is smoke-testing that
already. I know I get CPAN Testers reports for such perls but don’t know
if there is systematic or only sporadic effort there.

> Dependency-creep happens, sometimes in nonobvious ways, that lead to
> cyclic dependencies or other weird breakages - any non-core build
> system feels like it could be much more prone to gaining one of these
> by accident.

Once “latest stable perl” means a perl that ships without M::B, there
will be *many* CPAN smokers keeping that dep chain honest.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

[Leon Timmermans]

On Thu, May 23, 2013 at 11:16 PM, Paul LeoNerd <leo...@leonerd.org.uk> wrote:
> Ahh.. Yes; that part starts to feel tricky now.
>
> Does the whole of its dependency tree know quite clearly that it cannot
> use M::B at all then? Is this something that can somehow be enforced,
> or at least smoke-tested on?

A few months ago File::Temp suddenly switched to Module::Build (see
#84531), it broke stuff and was noticed after some time.

> Dependency-creep happens, sometimes in nonobvious ways, that lead to
> cyclic dependencies or other weird breakages - any non-core build
> system feels like it could be much more prone to gaining one of these
> by accident.

This kind of problem is fairly inherent to client-side toolchain
stuff. We have to be leaner on dependencies than other people out of
necessity, not out of choice.

Leon

[Leon Timmermans]

On Fri, May 24, 2013 at 3:52 AM, David E. Wheeler <da...@kineticode.com> wrote:
>> I will go poke some more people/groups who might care. Like: I'll go
>> cross-post.
>
> Someone is working for an install-only clone of Module::Build, right? I look forward to using that and switching to dzil for authoring.

Check out Module::Build::Tiny for example ;-)

Leon

[Tim Jenness]

On Thu, May 23, 2013 at 4:16 PM, Leon Timmermans <faw...@gmail.com> wrote:

On Thu, May 23, 2013 at 11:16 PM, Paul LeoNerd <leo...@leonerd.org.uk> wrote:
> Ahh.. Yes; that part starts to feel tricky now.
>
> Does the whole of its dependency tree know quite clearly that it cannot
> use M::B at all then? Is this something that can somehow be enforced,
> or at least smoke-tested on?

A few months ago File::Temp suddenly switched to Module::Build (see
#84531), it broke stuff and was noticed after some time.

It wasn't sudden really, in that the repository had been using Module::Build for a couple of years. It was sudden in the sense that I didn't tell anyone about it. This was because I was under the mistaken impression that Module::Build was the recommended way of distributing modules these days and that MakeMaker was effectively deprecated (that's that sense I got a few years back). I've been conscientiously migrating all my modules over to Module::Build and now I find that I should have left them with MakeMaker (or gone crazy and adopted Dist::Zilla).

I hadn't considered the problem of Module::Build needing File::Temp and File::Temp needing Module::Build.

-- 

Tim Jenness

[David Cantrell]

On Fri, May 24, 2013 at 12:23:08AM +0200, Aristotle Pagaltzis wrote:
> * Paul LeoNerd Evans <leo...@leonerd.org.uk> [2013-05-23 23:20]:
> > Is this something that can somehow be enforced, or at least
> > smoke-tested on?
> Anyone running a CPAN smoker under a pre-M::B perl is smoke-testing that

> already. I know I get CPAN Testers reports for such perls but don???t know

> if there is systematic or only sporadic effort there.

I test everything that gets released to the CPAN with perl 5.6.2
and 5.8.9. These days most of it doesn't actually build though
(especially with 5.6.2), and so doesn't generate any kind of report,
even if using cpXXXan for dependencies.

--
David Cantrell | semi-evolved ape-thing

There are many different types of sausages. The best are
from the north of England. The wurst are from Germany.
-- seen in alt.2eggs...

[David Cantrell]

On Thu, May 23, 2013 at 10:16:59PM -0700, Tim Jenness wrote:

> I hadn't considered the problem of Module::Build needing File::Temp and
> File::Temp needing Module::Build.

There's a tool for that!

http://deps.cpantesters.org/depended-on-by.pl?module=File::Temp

--
David Cantrell | Official London Perl Mongers Bad Influence

When a man is tired of London, he is tired of life
-- Samuel Johnson

[Steffen Mueller]

On 05/24/2013 01:42 AM, Ricardo Signes wrote:
> * David Golden <x...@xdg.me> [2013-05-22T13:44:38]

>> I propose deprecating Module::Build from core in 5.19 and removing it in
>> 5.21.
>

> I will go poke some more people/groups who might care. Like: I'll go
> cross-post.
>

> I don't expect any substantial objections, though, and think we'll end up doing
> this. That means:
>
> * add the "use deprecate" to Module::Build
> * ship it[1]
> * mark it deprecated in CoreList
> * set a timer for 5.21.0

This whole deal about nuking Module::Build from core concerns me.

The "nobody wants to maintain it" argument really doesn't cut it - if
M::B is broken by Perl, a significant fraction of CPAN will explode.
We'd have to fix it anyway. Furthermore, we should also expunge
ExtUtils::MakeMaker while we're at it. It's not seen a lot of love
either (despite the laudable claims of some).

Module::Build is rather low in the module building infrastructure and is
depended on by A LOT of code. In particular, non-core, non-CPAN build
systems may have logic that depends on M::B which will run into
"interesting" bootstrapping issues once its gone.

Generally speaking, killing this module in core seems to fall on the far
side of the "cost/benefit" line.

--Steffen

[Nicholas Clark]

On Fri, May 24, 2013 at 01:42:26PM +0200, Steffen Mueller wrote:
> On 05/24/2013 01:42 AM, Ricardo Signes wrote:
> > * David Golden <x...@xdg.me> [2013-05-22T13:44:38]
> >> I propose deprecating Module::Build from core in 5.19 and removing it in
> >> 5.21.
> >
> > I will go poke some more people/groups who might care. Like: I'll go
> > cross-post.
> >
> > I don't expect any substantial objections, though, and think we'll end up doing
> > this. That means:
> >
> > * add the "use deprecate" to Module::Build
> > * ship it[1]
> > * mark it deprecated in CoreList
> > * set a timer for 5.21.0
>
> This whole deal about nuking Module::Build from core concerns me.
>
> The "nobody wants to maintain it" argument really doesn't cut it - if
> M::B is broken by Perl, a significant fraction of CPAN will explode.
> We'd have to fix it anyway. Furthermore, we should also expunge

But Module::Build isn't doing anything that exotic, is it? It would be the
sort of change that would bust a bunch of other things, and we'd either
have to fix a lot of stuff, or not make the change.

Having it no longer in the core makes it clear to anyone considering what
build system to use that it's not looking like something with a future.

> ExtUtils::MakeMaker while we're at it. It's not seen a lot of love
> either (despite the laudable claims of some).

Yes, but a counter to that is that the core build uses ExtUtils::MakeMaker,
so it is our itch to scratch. The core doesn't use Module::Build, partly
because it *can't* use Module::Build, because Module::Build wasn't written
to be able to bootstrap the XS modules from non-XS. I suspect because that
wasn't part of its design goals.

> Module::Build is rather low in the module building infrastructure and is
> depended on by A LOT of code. In particular, non-core, non-CPAN build
> systems may have logic that depends on M::B which will run into
> "interesting" bootstrapping issues once its gone.

I tend to view what's on CPAN as the best approximation we have of what code
is "out there". If there isn't code on CPAN that can be identified that
breaks in such a way, I'd argue that it's unlikely that there is much
elsewhere. If there is code on CPAN, then I'd take it as an indicator of
the size of the "problem". To be fair, I haven't gone looking on CPAN for
this. But it isn't clear from your phrasing that you're confident of this
either.

> Generally speaking, killing this module in core seems to fall on the far
> side of the "cost/benefit" line.

I'm not sure. I hate the fact that we have been donated an albatross that
*we don't use* that it seems we are now implicitly expected to support
in perpetuity. It feels like bait and switch, because when it arrived it
was actively maintained by an external group. But that group has
dissipated. There was even a comment on the module-build list a year or
two ago to the effect of "but we made it [to core], and now someone else
looks after it".

Certainly, if it is to stay in core, I think that it should move to ext/
(ie *not* be dual life), be stated as being "bug fixes only", and we only
have to do work to support it on the current release. Not make it work on
all versions that the toolchain supports. (ie back to 5.8.1, as I understand
it)

If Module::Build end users like to use Module::Build, surely they should
pool to contribute to its upkeep?

Nicholas Clark

[Nicholas Clark]

On Thu, May 23, 2013 at 07:42:12PM -0400, Ricardo Signes wrote:
> * David Golden <x...@xdg.me> [2013-05-22T13:44:38]

> > I propose deprecating Module::Build from core in 5.19 and removing it in
> > 5.21.
>

> I will go poke some more people/groups who might care. Like: I'll go
> cross-post.
>
> I don't expect any substantial objections, though, and think we'll end up doing
> this. That means:
>
> * add the "use deprecate" to Module::Build
> * ship it[1]
> * mark it deprecated in CoreList
> * set a timer for 5.21.0
>

> [1]: If we only add the deprecate.pm usage to core's M::B, it means we'll
> either need to stop updating core's version or we'll need to reapply each time.
> I think it'll be easier to add it to the official repo, and I know a few people
> with the commit bits to make it happen. ;)

The intent of the (unfortunately named) deprecate pragma was exactly this.

That it gets added to the upstream codebase once, and from then on no further
changes are needed, and identical code (with identical $VERSIONs) is present
in both places.*

Nicholas Clark

* And the PAUSE indexer does not get upset and does not start to kill kittens.

[Reini Urban]

David,
Keeping CPAN happy with 5.6.2 and 5.8.9 is not so hard.

I keep a distroprefs for some rarely needed patches, but in fact
almost everything works on 5.6.2 and 5.8.9. At least some old versions,
until someone went berserk and removed support in newer versions.
Like to enforce LICENSE in EUMM metas.

--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/

[Alberto Simões]

Hello,

I noted this thread too late, and I have no time to read it all.
So, just a pair of comments:
- suggesting new people to use tools other than M::B, sure (not sure
of a better one yet)
- forcing people who are happy and using M::B in their distributions
to change, please no.

I fought for years with EU::MM to build some XS based libraries, and
M::B just made that possible with low effort. It might be evil (as
EU::MM), but it is making people happy.


Sorry if this is off-topic :)
Alberto

[John Peacock]

On 05/24/2013 09:54 AM, Ricardo Signes wrote:
> It isn't the most common way, or even the most recommended way.

What _is_ the most common way (I'll bet it is still EU::MM)? What is
the most recommended way?

John

[Nicholas Clark]

On Fri, May 24, 2013 at 03:05:10PM +0100, Alberto Sim�es wrote:
> Hello,
>
> I noted this thread too late, and I have no time to read it all.
> So, just a pair of comments:
> - suggesting new people to use tools other than M::B, sure (not sure
> of a better one yet)
> - forcing people who are happy and using M::B in their distributions
> to change, please no.
>
> I fought for years with EU::MM to build some XS based libraries, and
> M::B just made that possible with low effort. It might be evil (as
> EU::MM), but it is making people happy.

No-one is forcing anyone not to use Module::Build.

And toolchain support for configure_requires means that it should just keep
working in the future - CPAN clients will correctly download and install
Module::Build from CPAN.

So there's no forcing here.

Nicholas Clark

[Alberto Simões]

Good point.

> So there's no forcing here.

Great :-)

[Steffen Mueller]

The most common is certainly EU::MM. The most recommended is (IMNSHO)
whatever makes your module work: For some extensions to the build tools,
EU::MM is a horrible, horrible nightmare. For others, Module::Build is.

--Steffen

[H.Merijn Brand]

Well said :)

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.17 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

[Leon Timmermans]

On Fri, May 24, 2013 at 1:42 PM, Steffen Mueller
<ma...@steffen-mueller.net> wrote:
> The "nobody wants to maintain it" argument really doesn't cut it - if M::B
> is broken by Perl, a significant fraction of CPAN will explode. We'd have to
> fix it anyway. Furthermore, we should also expunge ExtUtils::MakeMaker while
> we're at it. It's not seen a lot of love either (despite the laudable claims
> of some).

I have been making that point for some years now: ExtUtils::MakeMaker
is just as undermaintained as Module::Build, but as others have
pointed out core actually depends on it. Bugs are stil getting fixed,
but new features are added at a glacial speed.

Leon

[Paul LeoNerd Evans]

On Fri, 24 May 2013 13:20:21 +0100
Nicholas Clark <ni...@ccl4.org> wrote:

> If Module::Build end users like to use Module::Build, surely they
> should pool to contribute to its upkeep?

I for one would very much like to keep it.

Do we have any suggestions for a suitable rallying-point, for such fans
to group around? Right now I don't really see any way to co-ordinate
this.

[Leon Timmermans]

On Fri, May 24, 2013 at 7:16 AM, Tim Jenness <tim.j...@gmail.com> wrote:
> It wasn't sudden really, in that the repository had been using Module::Build
> for a couple of years. It was sudden in the sense that I didn't tell anyone
> about it. This was because I was under the mistaken impression that
> Module::Build was the recommended way of distributing modules these days and
> that MakeMaker was effectively deprecated (that's that sense I got a few
> years back).

Module::Build was the recommended tool for some time, and then it went
out of vogue, for various reasons. After that it was Module::Install
that was the hottest thing, since it seemed to combine M::B's ease of
use for the author with ExtUtils::MakeMaker. That became a rather
top-heavy solution and seems to be the least maintained or recommended
option of them all nowadays.

Quite frankly, I do think we need to have better build tools to point
people at when we tell them "this is not really recommended anymore".
I still believe the core vision of Module::Build (a pure-perl build
tool) was the right one, but it's implementation is not salvageable.

> I've been conscientiously migrating all my modules over to
> Module::Build and now I find that I should have left them with MakeMaker (or
> gone crazy and adopted Dist::Zilla).

Generally speaking you should do whatever works for you, it's just
File::Temp that was being special.

> I hadn't considered the problem of Module::Build needing File::Temp and
> File::Temp needing Module::Build.

Yeah, we need to make sure all dependency maintainers are aware of
this issue, but that's just a matter of sending them a simple email.

Leon

[David Golden]

On Fri, May 24, 2013 at 11:23 AM, Paul LeoNerd <leo...@leonerd.org.uk> wrote:
> On Fri, 24 May 2013 13:20:21 +0100
> Nicholas Clark <ni...@ccl4.org> wrote:
>> If Module::Build end users like to use Module::Build, surely they
>> should pool to contribute to its upkeep?
>
> I for one would very much like to keep it.
>
> Do we have any suggestions for a suitable rallying-point, for such fans
> to group around? Right now I don't really see any way to co-ordinate
> this.

There is a Module::Build mailing list:
http://lists.perl.org/list/module-build.html

That is probably the right rallying-point, if there is anyone to rally.

When I announced I was stepping down as release manager in March 2011,
it wasn't until October 2011 that Leon graciously stepped up to be the
"caretaker" manager.

* http://grokbase.com/t/perl/module-build/113561ht1h/time-for-a-new-module-build-release-manager
* http://grokbase.com/t/perl/module-build/11an8kvz5g/new-module-build-patch-release-manager

And there have been no volunteers since to take on even the little bit
of housekeeping that Leon has done.

Regardless, I don't see it as having any place in core any more
because the CPAN toolchain has evolved to be able to bootstrap *any*
build tool, which wasn't the case back in 5.9.X.

David

[Karen Etheridge]

On Fri, May 24, 2013 at 10:43:44AM -0400, Ricardo Signes wrote:
> > What _is_ the most common way (I'll bet it is still EU::MM)? What
> > is the most recommended way?
>

> For commonly used things, according to their metadata:

How did you determine these numbers? (i.e. can you throw up your code in a
gist?)

It would be interesting to look at historical data to see trends - e.g.
via cp2000an.barnyard.co.uk and other historical indexes.

[Johan Vromans]

Leon Timmermans <faw...@gmail.com> writes:

> Quite frankly, I do think we need to have better build tools to point
> people at when we tell them "this is not really recommended anymore".

It is sufficient to say "«this» is the recommended way of doint it",
where «this» refers to said new tool.

Not having a flexible and robust build system for modules -- I don't
even mention installing applications -- has been one of my major perl
concerns for the last 25 years.

-- Johan

[Tatsuhiko Miyagawa]

On Wed, May 22, 2013 at 10:44 AM, David Golden <x...@xdg.me> wrote:

> * CPAN.pm has support for auto-detecting an undeclared dependency on
> Module::Build and installing it when needed [1]

Right now cpanm declares runtime dependencies to Module::Build (so
long as you install from CPAN clients, including itself) and doesn't
do special treatment to undeclared dependency to M::B like that.

Do you think I should change it to not declare M::B as cpanm's own dep
but auto-add Module::Build when Build.PL exists but configure_requires
isn't properly set?

> If you disagree, now is the time to speak up. Ideally, if you care
> enough about keeping Module::Build in core, you'll also volunteer to
> take over active maintenance for it, right? :-)

I'd personally like to see it kept just because it's one less thing to
worry about with bootstrapping, but i see the whole argument with
configure_requires already supported, etc.

I'd love to get the slow tests fixed by then, although p5p isn't the
right place to discuss about that.
https://github.com/Perl-Toolchain-Gang/Module-Build/issues/13


--
Tatsuhiko Miyagawa

[Tatsuhiko Miyagawa]

On Thu, May 23, 2013 at 6:52 PM, David E. Wheeler <da...@kineticode.com> wrote:

> On May 23, 2013, at 7:42 PM, Ricardo Signes <perl...@rjbs.manxome.org> wrote:
>
>> I will go poke some more people/groups who might care. Like: I'll go
>> cross-post.
>

> Someone is working for an install-only clone of Module::Build, right? I look forward to using that and switching to dzil for authoring.

Module::Build::Tiny that is.

I use it for my new projects exclusively, so long as they're pure perl
(which is 100% true for my use case :p) when authoring with
Dist::Milla https://metacpan.org/release/Dist-Milla


--
Tatsuhiko Miyagawa

[Leon Timmermans]

On Fri, May 24, 2013 at 8:21 PM, Tatsuhiko Miyagawa <miya...@gmail.com> wrote:
> Right now cpanm declares runtime dependencies to Module::Build (so
> long as you install from CPAN clients, including itself) and doesn't
> do special treatment to undeclared dependency to M::B like that.
>
> Do you think I should change it to not declare M::B as cpanm's own dep
> but auto-add Module::Build when Build.PL exists but configure_requires
> isn't properly set?

Before configure_requires people put that dependency in
build_requires, so you could also try to extract it from there.

> I'd love to get the slow tests fixed by then, although p5p isn't the
> right place to discuss about that.
> https://github.com/Perl-Toolchain-Gang/Module-Build/issues/13

Yeah, that's quite a headache with no obvious solution :-/

Leon

[David Golden]

On Fri, May 24, 2013 at 2:21 PM, Tatsuhiko Miyagawa <miya...@gmail.com> wrote:
> Do you think I should change it to not declare M::B as cpanm's own dep
> but auto-add Module::Build when Build.PL exists but configure_requires
> isn't properly set?

I'd see how many currently indexed distributions have a Build.PL and
no configure_requires first, maybe.

But it's a trivial edge case to address.

David


--
David Golden <x...@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

[James E Keenan]

When I was working on refactoring ExtUtils::ParseXS to work under 'use
strict' back in 2009-10, I had some scripts that identified the
breakdown on build tools. IIRC, ExtUtils::MakeMaker led Module::Build
by more than a 4 to 1 ratio. I suspect the ratio has stayed roughly the
same over time.

When we've ultimately done whatever we decide to do, it would be
interesting to have a retrospective on the course of M::B's development.
What succeeded? What didn't? What can we learn about open source
software development?

Note: I am *not* recommending we have that discussion now. Let's have
a discussion and set a course of action first.

Thank you very much.
Jim Keenan

[Jerome Quelin]

On 13/05/22 13:44 -0400, David Golden wrote:
> I propose deprecating Module::Build from core in 5.19 and removing it in 5.21.

As perl maintainer for Mageia, I approve every sane proposal to remove
modules from perl tarball.

> My rationale:
> [...]

And this time, it seems the proposal is sane and won't hurt anyone, so
I'd say go for it. And I'm saying that as a MB user for my modules.

my 2 cents,
Jérôme

[David Cantrell]

If anyone wants me to generate *all* the monthly indices, I can do that.
Shouldn't take very long either, as the CPAN was quite small back then.

--
David Cantrell | even more awesome than a panda-fur coat

Computer Science is about lofty design goals and careful algorithmic
optimisation. Sysadminning is about cleaning up the resulting mess.

[Karen Etheridge]

On Tue, May 28, 2013 at 12:14:24PM +0100, David Cantrell wrote:
> > > For commonly used things, according to their metadata:
> >
> > How did you determine these numbers? (i.e. can you throw up your code in a
> > gist?)
> >
> > It would be interesting to look at historical data to see trends - e.g.
> > via cp2000an.barnyard.co.uk and other historical indexes.
>
> If anyone wants me to generate *all* the monthly indices, I can do that.
> Shouldn't take very long either, as the CPAN was quite small back then.

+1 from me! many thanks!

[Joseph Brenner]

Paul LeoNerd <leo...@leonerd.org.uk> wrote:

Nicholas Clark <ni...@ccl4.org> wrote:

> If Module::Build end users like to use Module::Build, surely they
> should pool to contribute to its upkeep?

I for one would very much like to keep it.

Do we have any suggestions for a suitable rallying-point, for such fans
to group around? Right now I don't really see any way to co-ordinate
this.

I would like to second this point. 

I hear the argument "But no one is willing to maintain it!" a lot, but I don't see a lot of effort in trying to find maintainers.  Is there a list of abandoned core modules in need of attention?

[Leon Timmermans]

On Wed, May 29, 2013 at 12:15 AM, Joseph Brenner <doo...@gmail.com> wrote:
> I would like to second this point.
>
> I hear the argument "But no one is willing to maintain it!" a lot, but I
> don't see a lot of effort in trying to find maintainers. Is there a list of
> abandoned core modules in need of attention?

It has been discussed on the module-build list when David stepped down
as maintainer, and possibly here too I'm not sure about that anymore.

But if people are interested, I have ideas for things to do with M::B.
Proper Meta 2.0 support is fairly high on that list.

Leon

[David Golden]

Just to (maybe) cap the discussion, I want to share the blog post I
just wrote about Module::Build:

http://www.dagolden.com/index.php/2140/paying-respect-to-modulebuild/

[David Cantrell]

Done, from Jan 2000 onwards. If people think there's any value in going
any further back in time, please just ask.

--
David Cantrell | semi-evolved ape-thing

Us Germans take our humour very seriously
-- German cultural attache talking to the Today Programme,
about the German supposed lack of a sense of humour, 29 Aug 2001

[David Golden]

On Fri, May 31, 2013 at 12:37 PM, David E. Wheeler <da...@kineticode.com> wrote:
> My one objection to dropping M::B from core -- and it’s a minor one -- is that it becomes more of a PITA for people who don’t use the CPAN toolchain. This forces them to download and install Module::Build -- with all of its dependencies -- just to build and install something they downloaded. Lucy is a good example where this might come up:
>
> https://metacpan.org/release/Lucy

It requires Perl 5.8.3. How did it ever build there before
Module::Build was included in 5.10? It probably required some manual
effort. It will require some manual effort again.

Such distributions may want to explore Module::Build bundling:
https://metacpan.org/module/LEONT/Module-Build-0.4005/lib/Module/Build/Bundling.pod

David

[David Golden]

On Fri, May 31, 2013 at 8:19 PM, David E. Wheeler <da...@kineticode.com> wrote:
>> Such distributions may want to explore Module::Build bundling:
>> https://metacpan.org/module/LEONT/Module-Build-0.4005/lib/Module/Build/Bundling.pod
>

> Yeah, I guess that might be the best thing to do for such projects.

I still don't understand why someone wouldn't use the CPAN toolchain.
Or rather -- if someone is in an extremely constrained environment
(e.g. no Internet access allowed, no local minicpan allowed), then
they're living under such a strict security regime anyway that a
little bit of extra manual work is probably so typical as to not be a
concern.

Are these masochistic CPAN-avoiding users real or just boogeymen?

[Kent Fredric]

On 1 June 2013 14:02, David Golden <x...@xdg.me> wrote:

I still don't understand why someone wouldn't use the CPAN toolchain.

There's always the usecases for that where you are

- A (Linux)? Vendor of some kind packaging cpan into a binary dep ( debian etc )
- A (Linux)? Vendor of some kind who still installs stuff from source, but using vendor toolchain instead of CPAN clients. (Gentoo)

These cases are not really MB/P5P's concern, but its still helpful to acknowlege they exist, and while we do try telling users "If you want to do perl dev yourself, you want to use a Perlbrew rig", we still need perl via our toolchain as dependencies of other things that aren't distributed via CPAN, for instance: Munin, ImageMagick.

De-coring MB is not going to be a huge issue, because we've long had a QA metric that makes sure any dist that has a "Build.PL" file depends on a virtual to make sure Module::Build is present on their system, and that should be a seamless transition on Perl5.20, because we'll just re-point the virtual to the non-core version of MB.

I've had more issues as a result of the recent changes where Build.PL != MB, which breaks a few of the assumptions the MB metric is based upon, which has made automated downstream dist generation a little harder for me.

For instance, for some reason we've been using the not-fully-implemented but advertised feature ./Build pure_install[1][2] and this command seems to be missing in MB alternatives.

And I'm still trying to work out how to make a useful QA metric that will make sense when I see the first dist in our tree that is entirely self dependent, but still uses the Module::Build API, because simply the presense of a Build.PL is an insufficient metric, and I don't think we can evaluate Perl code / scrape Build.PL / META.* to answer that question reliably either, at least, not without hard-coding a list of things to scrape for. ( and simply scraping META.* for dependencies and trying to compare them with our own will prove useless, because nothing in there is in a format anything like what we have downstream )

TLDR: MB decoring itself is not a problem for our non-cpan toolchain, there's more problems that are simply resulting from how people respond to this decoring.

[1]: Documented https://metacpan.org/module/LEONT/Module-Build-0.4005/lib/Module/Build.pm#pure_install  ,
[2] implemented https://metacpan.org/source/LEONT/Module-Build-0.4003/lib/Module/Build/Base.pm#L3569
--
Kent

[David Golden]

On Sat, Jun 1, 2013 at 3:44 AM, Kent Fredric <kentf...@gmail.com> wrote:
> There's always the usecases for that where you are
>
> - A (Linux)? Vendor of some kind packaging cpan into a binary dep ( debian
> etc )
> - A (Linux)? Vendor of some kind who still installs stuff from source, but
> using vendor toolchain instead of CPAN clients. (Gentoo)
>
> These cases are not really MB/P5P's concern, but its still helpful to
> acknowlege they exist

Agreed -- but from an end user perspective, they should be fine as
long as they stick with their vendor's approach.

> I don't think we can evaluate
> Perl code / scrape Build.PL / META.* to answer that question reliably
> either, at least, not without hard-coding a list of things to scrape for. (
> and simply scraping META.* for dependencies and trying to compare them with
> our own will prove useless, because nothing in there is in a format anything
> like what we have downstream )

I don't really understand how your phrased that, but suggest that you
take it upon another thread (maybe on cpan-w...@perl.org) or on
#toolchain on IRC. The only way to find dependencies authoritatively
is to read META.json for prereqs/configure/requires -- install those
-- and then run Build.PL/Makefile.PL to generate MYMETA.json and then
read that. Whether you do that on the fly or do that "offline" and
store the result for your platform doesn't matter, but if you don't,
then you're not picking up dependencies correctly. How you translate
modules into packages in your vendor system is another tricky thing --
but presumably you've got something for that already.

[Johan Vromans]

"David E. Wheeler" <da...@kineticode.com> writes:

> In related news, if anyone here could point me to the right place to
> get some of my stuff pushed into Yum and Deb repositories, I would
> appreciate it.

For RedHat / Fedora Yum:

https://fedoraproject.org/wiki/Category:Package_Maintainers?rd=PackageMaintainers

-- Johan

[Aristotle Pagaltzis]

* David E. Wheeler <da...@kineticode.com> [2013-06-01 20:40]:

> On May 31, 2013, at 7:02 PM, David Golden <x...@xdg.me> wrote:
> > Are these masochistic CPAN-avoiding users real or just boogeymen?
>

> I’m thinking of people who just want to download, build, and install
> an app, folks who aren’t aware of the CPAN toolchain and just want to
> build something that is not provided by their distribution.

Surely the answer is to point them at cpanm?

[David Golden]

On Sat, Jun 1, 2013 at 6:16 PM, Aristotle Pagaltzis <paga...@gmx.de> wrote:
> Surely the answer is to point them at cpanm?

The "answer" is to point them at "cpan", which auto-configures and --
by 5.20 -- doesn't even bother with mirror selection. It will
bootstrap local::lib as well. Newbies should be able to say "cpan
Foo" and it will just work -- and give them instructions for how to
put local::lib in their shell.

Is it as pretty (e.g. terse) as cpanm? No. But it comes with the
perl core. (That said, if someone's distro doesn't HAVE cpan
installed, then it's a toss up whether installing it via package
manager is "easier" than downloading cpanm from the web.

[Aristotle Pagaltzis]

* David Golden <x...@xdg.me> [2013-06-02 03:10]:

> The "answer" is to point them at "cpan", which auto-configures and --
> by 5.20 -- doesn't even bother with mirror selection. It will
> bootstrap local::lib as well. Newbies should be able to say "cpan Foo"
> and it will just work -- and give them instructions for how to put
> local::lib in their shell.

If they download an off-CPAN app that isn’t meant for installing then
they can unpack the tarball and `cpanm --installdeps .`. Does `cpan`
have an equivalent for that? For that matter, though less importantly,
does it have `cpanfile` support? How much had the index loading been
optimised – does it download and parse fast enough to be unnoticeable
even on modest machines, and does it fail to die when operating with
limited RAM? The reduced default verbosity is only the most visible
aspect of cpanm, and not unimportant, but far from primary.

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

[Tatsuhiko Miyagawa]

On Sun, Jun 2, 2013 at 10:06 AM, David Golden <x...@xdg.me> wrote:
> On Sat, Jun 1, 2013 at 6:16 PM, Aristotle Pagaltzis <paga...@gmx.de> wrote:
>> Surely the answer is to point them at cpanm?
>
> The "answer" is to point them at "cpan", which auto-configures and --
> by 5.20 -- doesn't even bother with mirror selection. It will
> bootstrap local::lib as well. Newbies should be able to say "cpan
> Foo" and it will just work -- and give them instructions for how to
> put local::lib in their shell.

Looking forward to seeing that happen.

cpanm integrates local::lib already, and automatically sets up ~/perl5
when there's no write access to the site_perl and bin directory, and
emits an instruction how to set it up. The documentation could be
improved, and I'll be happy to work with you on that one to make it
consistent with the CPAN.pm equivalent.



--
Tatsuhiko Miyagawa

[Andreas Koenig]

Aristotle Pagaltzis <paga...@gmx.de> writes:

> * David Golden <x...@xdg.me> [2013-06-02 03:10]:
>> The "answer" is to point them at "cpan", which auto-configures and --
>> by 5.20 -- doesn't even bother with mirror selection. It will
>> bootstrap local::lib as well. Newbies should be able to say "cpan Foo"
>> and it will just work -- and give them instructions for how to put
>> local::lib in their shell.
>
> If they download an off-CPAN app that isn’t meant for installing then
> they can unpack the tarball and `cpanm --installdeps .`. Does `cpan`
> have an equivalent for that?

cpan .

> For that matter, though less importantly,
> does it have `cpanfile` support? How much had the index loading been
> optimised – does it download and parse fast enough to be unnoticeable
> even on modest machines, and does it fail to die when operating with
> limited RAM? The reduced default verbosity is only the most visible
> aspect of cpanm, and not unimportant, but far from primary.

I think I would accept a patch for that.

--
andreas

[Aristotle Pagaltzis]

* Andreas Koenig <andreas.koe...@franz.ak.mind.de> [2013-06-02 08:50]:

> Aristotle Pagaltzis <paga...@gmx.de> writes:
> >* David Golden <x...@xdg.me> [2013-06-02 03:10]:
> >>The "answer" is to point them at "cpan", which auto-configures and
> >>-- by 5.20 -- doesn't even bother with mirror selection. It will
> >>bootstrap local::lib as well. Newbies should be able to say "cpan
> >>Foo" and it will just work -- and give them instructions for how to
> >>put local::lib in their shell.
> >
> >If they download an off-CPAN app that isn’t meant for installing then
> >they can unpack the tarball and `cpanm --installdeps .`. Does `cpan`
> >have an equivalent for that?
>
> cpan .

No. That will install the distribution from the current directory.

Using `cpan --installdeps .` won’t. That will install the dependencies
of the distribution *only*, but not the distribution itself.

(Which, if it’s using cpanfile instead of Makefile.PL or Build.PL, may
not be a distribution at all, but a Perl app with CPAN dependencies.)

> >For that matter, though less importantly, does it have `cpanfile`
> >support? How much had the index loading been optimised – does it
> >download and parse fast enough to be unnoticeable even on modest
> >machines, and does it fail to die when operating with limited RAM?
> >The reduced default verbosity is only the most visible aspect of
> >cpanm, and not unimportant, but far from primary.
>
> I think I would accept a patch for that.

For what? I listed several things… you mean for all of them?

[Andreas Koenig]

Aristotle Pagaltzis <paga...@gmx.de> writes:

>> cpan .
>
> No. That will install the distribution from the current directory.

Without an example distribution you are talking about I cannot really
see a big difference.

> Using `cpan --installdeps .` won’t. That will install the dependencies
> of the distribution *only*, but not the distribution itself.
>
> (Which, if it’s using cpanfile instead of Makefile.PL or Build.PL, may
> not be a distribution at all, but a Perl app with CPAN dependencies.)
>
>> >For that matter, though less importantly, does it have `cpanfile`
>> >support? How much had the index loading been optimised – does it
>> >download and parse fast enough to be unnoticeable even on modest
>> >machines, and does it fail to die when operating with limited RAM?
>> >The reduced default verbosity is only the most visible aspect of
>> >cpanm, and not unimportant, but far from primary.
>>
>> I think I would accept a patch for that.
>
> For what? I listed several things… you mean for all of them?

Well done patches have traditioanlly been accepted in CPAN.pm. Recently
somebody put it that way on p5p (recalling from memory): patches are
accepted on merit, they are not pre-authorized.

--
andreas

[Dominic Hargreaves]

On Sat, Jun 01, 2013 at 11:35:02AM -0700, David E. Wheeler wrote:
> On May 31, 2013, at 7:02 PM, David Golden <x...@xdg.me> wrote:
>

> > Are these masochistic CPAN-avoiding users real or just boogeymen?
>

> I’m thinking of people who just want to download, build, and install an app, folks who aren’t aware of the CPAN toolchain and just want to build something that is not provided by their distribution.
>

> In related news, if anyone here could point me to the right place to get some of my stuff pushed into Yum and Deb repositories, I would appreciate it.

For Debian, report an RFP bug here:

http://www.debian.org/devel/wnpp/

(or even better: read up on [1] and [2] and (for perl stuff) [3] and get
involved directly :)

Cheers,
Dominic.

[1] <http://www.debian.org/doc/manuals/maint-guide/>
[2] <http://wiki.debian.org/DebianMentorsFaq>
[3] <http://wiki.debian.org/Teams/DebianPerlGroup/Welcome>

--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

[Shlomi Fish]

Hi David,

On Sat, 1 Jun 2013 11:35:02 -0700

"David E. Wheeler" <da...@kineticode.com> wrote:

> On May 31, 2013, at 7:02 PM, David Golden <x...@xdg.me> wrote:
>

> > Are these masochistic CPAN-avoiding users real or just boogeymen?
>

> I’m thinking of people who just want to download, build, and install an app,
> folks who aren’t aware of the CPAN toolchain and just want to build something
> that is not provided by their distribution.
>
> In related news, if anyone here could point me to the right place to get some
> of my stuff pushed into Yum and Deb repositories, I would appreciate it.
>

For Mageia Linux ( https://www.mageia.org/en/ ;
http://en.wikipedia.org/wiki/Mageia ) you can contact the Mageia perl
packagers such as me or Jerome Quelin and we can package it for you using

http://blogs.perl.org/users/shlomi_fish/2012/08/tech-tip-how-to-package-and-maintain-cpan-distributions-in-mageia.html

Regards,

Shlomi Fish

> Thanks,
>
> David
>



--
-----------------------------------------------------------------
Shlomi Fish http://www.shlomifish.org/
Optimising Code for Speed - http://shlom.in/optimise

CPAN thrives *because* of the unfettered uploading of shit, not in spite of it.
— Andy Lester

Please reply to list if it's a mailing list post - http://shlom.in/reply .

[David Cantrell]

On Fri, May 31, 2013 at 10:02:14PM -0400, David Golden wrote:

> Are these masochistic CPAN-avoiding users real or just boogeymen?

They are, sadly, real. There are people out there who somehow got a
meme into their heads that CPAN == dependency hell. I was told recently
that CPAN was unusable because it tries to upgrade perl. I forget when
that bug was fixed. Ten years ago? Something like that. I have no idea
how prevalent they are though.

I am one of the maintainers of one such project, which has a historical
policy of no dependencies other than perl itself and rsync. It
reimplements many many wheels, repeats vast swathes of code many times,
and has virtually no tests. And it uses autoconf. Hahahahaha!

It's not had a release in something like 5 years, despite there being
many bugfixes and improvements on github, an active user community, ...

I'd love to fix that project, but the lack of tests mean that doing so
is even more painful than leaving it as it is. One day I might get
round to "fixing" it, by throwing away all the existing code and
starting again from scratch.

Having said all that, and despite one of my many hats being a We Don't
Use The CPAN On This Project hat, I don't care about those people. They
have deliberately chosen pain, and so I'm quite happy for them to suffer
bitter hurts.

--
David Cantrell | Official London Perl Mongers Bad Influence

You can't spell AWESOME without ME!