Re: [gentoo-python] Concept for optional Python dependency and USE-flag deps in p-d-ng

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3283 bytes --]

On Sun, 9 Sep 2012 11:21:56 -0400
Mike Gilbert <floppym@gentoo.org> wrote:

> On Sun, Sep 9, 2012 at 4:33 AM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > Hello,
> >
> > After some thinking, I think I found an optimal solution to
> > implementing various kinds of Python dependencies and
> > PYTHON_USE_WITH*.
> >
> > As a note, all variable names are dirty and not official. Feel free
> > to suggest better ones.
> >
> > 1. Add a user-defined variable PYTHON_USE. If user needed any
> > specific flags from a Python dependency, he can set the USE
> > dependency string there. The string will have to follow the general
> > rules for USE dependencies and be correct for every Python
> > implementation specified in PYTHON_COMPAT (this may require USE
> > defaults). For example:
> >
> >     PYTHON_USE="ncurses,sqlite"
> >
> > 2. Add a eclass-defined variable PYTHON_DEPEND. It will be always
> > exported, and contain a dependency string created using
> > PYTHON_COMPAT and PYTHON_USE -- the most simple and most common
> > one, e.g.:
> >
> >     PYTHON_DEPEND="
> >       python_targets_pythonX_Y?
> >         ( dev-python/python:X.Y[ncurses,sqlite] )
> >     "
> >
> > 3. By default, just append PYTHON_DEPEND to DEPEND and RDEPEND.
> > Provide an option to disable that. If user wants optional Python,
> > he can disable it and use ${PYTHON_DEPEND} in his own *DEPEND code.
> > (we could also provide a quick switch to add 'python? ( )' or
> > '$USEFLAG? ( )').
> >
> 
> I like the idea of the PYTHON_DEPEND variable and the option to
> disable its addition to DEPEND and RDEPEND. That makes it simple to
> control for packages which only need python for building, for example.
> 
> I don't think we really need the switch you mention for controlling
> optional python dependencies, but I guess it couldn't hurt.
> 
> > 4. Finally, provide a general, parametrized dependency generator
> > function which will be useful in all the remaining non-common cases
> > which can't be handled sanely by any other solution.
> >
> 
> Sounds good to me. We should hash out exactly what parameters it would
> take; hopefully we can make it flexible enough to deal with changes in
> dependency atoms in future EAPIs.
> 
> As I interpret your example, your hypothetical function takes a list
> of use flags as $1, and the rest of the parameters are python targets.
> Maybe we should put the use flag list behind a switch? I'm mainly
> thinking of scenarios where various python implementations support
> different use flags.

I'm not sure about this flag list. I have put a bit of thought and I've
come to the following conclusion:

1) If a particular Python version doesn't support a particular feature,
then it can't go into supported implementations because it is
pointless.

If the feature is conditional it's really hard to say what to do. We
could use REQUIRED_USE to make it a bit more sensible but it's, well,
weird if you installed a package for three variants of Python and only
two of them have a particular feature you have enabled.

2) If a particular Python version does support the feature
unconditionally, flag(+) is probably enough.

Am I missing something?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]