On Fri, Sep 11, 2009 at 8:07 PM, Ron Savage <r...@savage.net.au> wrote: > o Obviously module authors can just not implement anything based on this > new mechanism, but for those who do...
Nothing would happen by default. The idea is that if you replace "use Module::Build" in your Build.PL with "use inc::latest 'Module::Build'" then the auto-bundling will get switched on. > o A depth limit: Just how deeply will dependencies be nested? Does it > matter? To work correctly, for distribution Foo, every one of Foo's 'configure_requires' dependencies and all of the 'requires' dependencies of those must be bundled. How exactly those get nested into inc/inc_* is part of the design discussion. > o Sabotage: What if someone maliciously nests dependencies, triggering > excessive attempts to satisfy dependencies (i.e. a Denial of Service > attack)? Will some protection against this be built in? Dependency bundling would happen by the author prior to upload to CPAN. End users during install shouldn't notice a thing. Nothing prevents anything bundled from doing something malicious any more than any of the arbitrary code that runs during the install process. Note: nothing bundled in inc gets installed -- it's just there to let Build.PL finish running and identify subsequent dependencies. Those would be resolved as normal by CPAN(PLUS) or "Build installdeps" (which uses CPAN(PLUS) anyway). > o Compulsion: Is the new mechanism turned on by default simply because > it's present in the distro? Will clients (i.e. people) be able to turn > if off? Does turning it off make any sense? The idea of "inc::latest" is that you get the latest version of whatever module is loaded. If you have M::B 0.35 bundled in inc, but M::B 0.36 installed on your system, inc::latest will load M::B 0.36 from your system. But if you only have 0.34 installed, then the bundled M::B will be loaded instead. Thus you "turn it off" by having all the configure_requires dependencies installed with a version equal to or later than what is bundled. This will happen *automatically* with any recent CPAN(PLUS) client. They will make install (or otherwise make available) all configure_requires listed in META.yml before running Build.PL, in which case nothing bundled will ever get loaded. It's already part of 5.10.1. And for the rest of the Perl universe, it's a one time upgrade of CPAN.pm or CPANPLUS and then for the rest of time, configure_requires will be enabled and will take care of pre-configuration dependencies. All this inc bundling is just a stopgap for those poor souls who aren't allowed or don't know how to upgrade CPAN.pm. > o Off-line: For those of us who work on machines with no mini CPAN and > no internet access, I assume this mechanism will be self-contained, in > that everything will 'just work' without that access? Yes? As an end-user, it will "work", but of course, if you're offline and have no minicpan, how are you even downloading the distribution to install it in the first place? As an author, maybe or maybe not, depending on how we implement it. The issue is dependency resolution of configure_requires. Let's say you want to use Devel::CheckLib. That happens to depend on IO::CaptureOutput. If you've installed Devel::CheckLib, then you've got IO::CaptureOutput on your system, but there's no foolproof way to tell that Devel::CheckLib requires it and that it needs to be bundled. Module::ScanDeps is an option, but it can miss things. The safest, most robust thing to do is to get the Devel::CheckLib META.yml and get the 'requires' list from there and that needs a net connection or minicpan. We could implement various heuristics and 9/10 times it will work fine. Or, we can say that you can't "Build distdir" unless you have access to a CPAN. You can develop and test and do all that, but the actual build of a dist directory couldn't happen. Ultimately, I don't think putting that constraint on authors is too great a burden. (Side editorial -- I can't fathom why you would be developing offline without a minicpan. It's so easy to set up and only about a gig. I love being on an airplane at 30k feet and finding I want some module and being able to install it right then and there.) -- David
