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

[Mike Gilbert]

On Sun, Sep 9, 2012 at 4:33 AM, Michał Górny <mgorny@g.o> 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.