develooper Front page | perl.perl5.porters | Postings from June 2013

Re: RFC: Deprecating Module::Build

Thread Previous | Thread Next
From:
Kent Fredric
Date:
June 1, 2013 07:44
Subject:
Re: RFC: Deprecating Module::Build
Message ID:
CAATnKFBXKA86q9qcBSvD_3npq8SkGRMnaNetda42SRJM0J-8Og@mail.gmail.com
On 1 June 2013 14:02, David Golden <xdg@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

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About