Front page | perl.perl5.porters |
Postings from December 2016
On Mon, Dec 5, 2016 at 6:10 PM, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote: > A few years back there was an oft-cited sort-of rule (but maybe more of > an aspiration) that we should only have modules in core that are needed > to build perl itself or to install modules from CPAN. > > Obviously at the time we already have a bunch of stuff grandfathered in, > and we didn’t even have a procedure for getting things back out. In part > that was because it is actually very hard to really get things out once > you consider perl at the OS vendor package level rather than just within > the CPAN bubble. > > Even so, the rule leaves grey area around modules that implement things > which are in some sense part of the language without being built into > the interpreter directly, like Time::Piece being based on a old Larry > design for localtime’s return value, or the Scalar/List/Hash::Util stuff > (at least some of which really ought to have been inside the interpreter > itself… an old story). > > Is Module::Runtime either of these? It does not seem that way to me. > > > Here's my basic pitch: > > The rule I mentioned was a reaction to the bad old days of when CGI.pm > in core acted as a drag on adoption of better CPAN-based alternatives. > And it was added to core because it had won the market. We should, at > the least, not go back to that way of doing things without awareness of > how we got where we are. > > Esp. given how costly it is to our downstreams when we realise we need > to course-correct. > I think I agree. The main reason in favor seems to be "it would be one dependency less for a number of commonly used frameworks", which isn't that much of a good reason. If anything, I'd lean towards fixing Module::Load, if only because we actually have other modules in core that already depend on it (mostly via Module::Load::Conditional). LeonThread Previous | Thread Next