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
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


Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
postedApr 10, '08 at 6:46p
activeApr 10, '08 at 6:46p

1 user in discussion

Hans Dieter Pearcey: 1 post



site design / logo © 2021 Grokbase