Front page | perl.perl5.porters |
Postings from June 2013
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 -- KentThread Previous | Thread Next