# from John Peacock # on Monday 17 July 2006 10:59 am: >Anyways, moot points all around... Nothing to see here... Move > along, move along... ;-)
Your EU::MM support in version.pm solves this case, but M::B will never add another dependency? >Eric Wilhelm wrote: >> Was there a discussion at one point about M::B bundling and/or >> bootstrapping its non-core dependencies? > >This discussion is complicated by the fact that both M::B and version >will be core in 5.10.0, so we only need to deal with fresh installs. Correct me if I'm wrong, but doesn't "non-core" in this context need to mean "non-core anywhere in 5.*.*" ? >> AFAIK, EU::MM never depended on anything that hadn't always been >> core. > >Well, version can depend on EU::MM, because EU::MM is core... I only mentioned that as a point of comparing M::B to its predecessor. >> Which would hurt less? >> >> 1. bundling dependencies >> - "cpan version" would cause two installs of version.pm (big >> deal?) > >This last point is actually a big deal. If we had gone the bundled >route, we'd have to make sure that cpan only indexed the standalone >version.pm release, err, I actually had a slightly different scenario in mind (below), but doesn't the META.yml cover the indexing issue? http://module-build.sourceforge.net/META-spec-v1.2.html#no_index >since otherwise it could happen that trying to >install only version.pm would also install Module::Build. If version.pm build_requires Module::Build, then "cpan version" would first install M::B, which would install it's bundled version.pm, after which cpan would proceed to finish the originally requested version.pm install (which may be a newer version than the bundled one depending on the latest release ordering.) This would even be desirable if version.pm gets way more active that M::B at some point. If anything, the optimization here would be for cpan to notice that M::B has just installed the same version of version.pm that triggered the M::B install, but worst case is that it overwrites ~15 files with identical copies of themselves, right? If you want to maintain parallel EU::MM and M::B files for version.pm, that's up to you. I'm just wondering what happens when any of these (there may be more -- this is just a quick check against 5.8.8 core) decide to switch to using M::B? Module::Signature ExtUtils::ParseXS Archive::Tar Pod::Readme ExtUtils::CBuilder YAML Pod::HTML I'm thinking M::B should bundle even its optional dependencies so it can ask me if I want the feature and dwiw without me having to install stuff and then reconfigure it (I'm still not clear on exactly how the optional features are configured.) If recursive builds could support EU::MM sub-distributions as well as M::B, wouldn't including these in the dist be a simple untar? What's 404k compared to the convenience of a "yyyyyy" full-featured install on a fresh perl? --Eric -- software: a hypothetical exercise which happens to compile. --------------------------------------------------- http://scratchcomputing.com ---------------------------------------------------
