[Exherbo-dev] Python improvements

Ciaran McCreesh ciaran.mccreesh at googlemail.com
Wed Jul 20 21:31:14 BST 2011


On Wed, 20 Jul 2011 19:59:55 +0000
Paul Seidler <pl.seidler at googlemail.com> wrote:
> > On Mon, 18 Jul 2011 22:55:16 +0000
> > Paul Seidler <pl.seidler at googlemail.com> wrote:
> > > I think it would be really nifty if suboptions can be treated like
> > > options, so that there could be an suboption python with a
> > > description and when the option is enabled the different python
> > > versions appear and can be enabled/disabled.
> >
> > Could you explain what you mean by that please?
> 
> I'll try it but I've modified the idea a little bit:
> I mean to bind an option to a suboption (in this case PYTHON to
> python) so if -python is selected you don't get the "PYTHON:*" output
> for resolving foo/bar.
> e.g. git:
> +python: " -xinetd PYTHON: -2.6 2.7 -3.1 build_options: "
> -python: " -xinetd build_options: "

Oh. You mean, not having certain options shown at all if other options
aren't selected? There are three things sort of relevant to this
currently.

First, there's HIDDEN_SUBOPTIONS, which is used to unconditionally hide
a suboptions group.

Second, there's MYOPTIONS requirements, which can be used to express
interdependencies between options.

I wonder whether something like this is the way to go:

    MYOPTIONS="
        python
        ( python_abis: 2.6 2.7 ) [[ *hidden-if = [ !python ] ]]
        "

Except I'm worried it'll be abused... In particular, I suspect people
will use it when they should just be using requires -- usually options
should be visible, even if an option they require is disabled.

Third, choices (which is what options map to in Paludis internals)
support having values, as per build_options: jobs and symbols. If an
option is off, its values are irrelevant. So maybe instead:

    MYOPTIONS="
        python [[ values = [ 2.6 2.7 3.1 ] ]]
        "

But then we have to introduce a whole new mechanism for values, since
values have interdependencies and can be used in dependencies and so on.

Or maybe we could map an option with values onto a suboption somehow...
So doing this:

    MYOPTIONS="
        python [[ values = [ 2.6 2.7 3.1 ] ]]
        "

would automatically give you something equivalent to:

    MYOPTIONS="
        python [[ values = [ 2.6 2.7 3.1 ] ]]
        ( python: 2.6 2.7 3.1 )
        "

for the purposes of dependencies etc, and where the suboption would
automatically be hidden.

Also, I dunno if there are issues having a suboption named the same as
an option. Or for that matter whether having it named PYTHON would upset
configure scripts -- I suspect some packages probably look at the
$PYTHON environment variable to find Python and will get upset if it
contains "2.6 2.7".

-- 
Ciaran McCreesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20110720/ffc6605f/attachment.pgp>


More information about the Exherbo-dev mailing list