[Exherbo-dev] Python improvements

Paul Seidler pl.seidler at googlemail.com
Thu Jul 21 03:44:36 BST 2011


20.07.2011, 21:31 +0100 schrieb Ciaran McCreesh:
> 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.

Exactly!

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

Unfortunately this is no solution for this case.

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

I like this one for the simplicity, but also I see the resulting trouble
rise at the horizon.

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

This one is clearly my favorite and I think that's the "clean-way"(TM)
especial the first part of it. Tragically, the "right" way is usually a
synonymous for the most work.
For a map I'm more thinking in this direction:
MYOPTIONS="python [[ bind_suboption=PYTHON ]]"

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

Indeed, maybe that can be a problem. I run into a similar problem with
dev-scm/git, as PYTHON is also the string which is used to transport the
used python executable and it got replaced in "option_with". I have to
look at this again and will probably rename the suboption to python_abi
(thanks for the suggestion).
This would also make that discussion superfluous (at least regarding the
python suboption) because I think it will not be confusing anymore (with
a reworded description of python_abi:*). Sometimes the answers are so
simple that you can't see them.
Of course it would be still nifty if it can be handled like in your
third idea.




More information about the Exherbo-dev mailing list