Front page | perl.cpan.workers |
Postings from April 2008
On Thu, Apr 10, 2008 at 08:49:31AM +0200, Andreas J. Koenig wrote: > hdp> Changing distroprefs to load additional preferences (or re-match based on > hdp> additional information including installers) may not be entirely crazy, but it > hdp> adds a level of complexity I wouldn't really want to get into unless it was > hdp> clearly needed. > > No, that's already there! Mostly untested but in place. The major > obstacle at the moment is that nobody specifies dynamic_config=0 in > their META.yml and so I cannot use the optional_features that I find > there. Hmm, I'll have to take another look at that; it sounds interesting. > hdp> Making all installers act the same has a lot of potential benefits (c.f > hdp> INSTALL_BASE). Something like > > hdp> perl Makefile.PL FEATURES=optional_deps=-all (-none Foo::Bar,Baz::Quux) > > hdp> perl Build.PL --features optional_deps=-all > > except that this syntax is really not pretty. I think something as > short as --features=:all needs to be chosen. It must be short, easy to > grasp and the right thing for a majority. You're right. 'all' and 'none' are the most important anyway; while it might be nice to be able to say "no optional dependencies, all scripts", that's clearly not worth optimizing for at this point. (-all vs. :all I don't care about -- the leading dash was just the first thing that came to mind as "something that does not look like a module or script".) I didn't realize (before) that EUMM and M::B would silently ignore --features or FEATURES= if they didn't recognize the argument. That makes things much easier to deal with -- I had assumed they'd cause installation to abort. Oops. I am not incredibly worried about the syntax, and I agree that the optional_deps= thing I suggested above is not very pretty. It could be useful to provide a standard way to communicate things like "should I run tests that use a network connection" or "should I install an XS version of this module"; these aren't necessarily the right thing to put into 'features', but are they worth trying to solve in a similar way? Right now, everyone does their own thing, as evidenced by the large number of expect and eexpect sections in cpanpm/distroprefs. hdp.