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

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

[Michał Górny]

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

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? ( )').

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.

For example, the following ::progress string:

  PYTHON_DEPEND="<<[xml]>> database? ( <<[gdbm]>> ) gui? ( <<[tk]>> )"

could be obtained using:

  PYTHON_COMPAT=...
  PYTHON_USE=xml
  inherit python-distutils-ng
  RDEPEND="
    ${PYTHON_DEPEND}
    database? (
      $(python-gen-depend gdbm ${PYTHON_COMPAT})
    )
    gui? (
      $(python-gen-depend tk ${PYTHON_COMPAT})
    )
  "

or even hackier (but faster):

  RDEPEND="
    ${PYTHON_DEPEND}
    database? (
      ${PYTHON_DEPEND//\[xml\]/[gdbm]}
    )
    gui? (
      ${PYTHON_DEPEND//\[xml\]/[tk]}
    )
  "

-- 
Best regards,
Michał Górny

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

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

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

[Michał Górny]

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