[gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages

[gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages

[Michał Górny]

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

Hi,

TL;DR: should we depend on setuptools by default?  Alternatively, should
we add distutils_enable_setuptools API to provide at least partial
validity checks.


The problem
===========
The vast majority of Python packages nowadays uses setuptools as their
build system.  According to a cheap grep, 1633 out of 2415 packages
using distutils-r1 depends on it -- and I suspect the vast majority of
those that do not are simply missing the dependency.

Are there valid cases for not using setuptools?  Notably, packages
needed to bootstrap setuptools aren't using it.  Plus some simple
packages that really don't need its features.

There are also packages that use setuptools but have distutils fallback.
We don't like them because switching between build systems involves file
<-> directory replacement that isn't handled cleanly by our package
managers.  Therefore, we want to always force one build system in them.

The setuptools dependency is so common it's easy to miss.  Notably, it's
a prerequisite of specifying package dependencies, so it's normally not
listed in dependencies.

Finally, while most of the time setuptools is just BDEPEND, there are
cases when it's RDEPEND as well.  The most common is the use
of entry_points -- and again, upstreams don't mention it explicitly.

All that considered, I think we should work on providing a better API
for depending on setuptools, to reduce the number of missing
dependencies and make it possible to automatically test for them
(reminder: PMS doesn't permit inspecting *DEPEND).


Variant 1: automatic dependency on setuptools
=============================================
Basically, we add a new trinary pre-inherit variable:

DISTUTILS_USE_SETUPTOOLS=no
  -> no deps
DISTUTILS_USE_SETUPTOOLS=bdepend
  -> add to BDEPEND (the default)
DISTUTILS_USE_SETUPTOOLS=rdepend
  -> add to BDEPEND+RDEPEND

This is roughly 'erring on the safe side'.  The default will work for
the majority of packages.  We will have to disable it for setuptools
bootstrap deps, and devs will be able to adjust it to correct values
as they update ebuilds.  For the time being, existing *DEPEND
on setuptools will avoid breaking stuff.

This will also enable me to add extra QA checks to esetup.py.  It should
be able to reasonably detect incorrect value and report it.  This will
imply some 'false positives' for packages that use the old method of
specifying setuptools in RDEPEND but that's a minor hassle.

Pros:
- works out of the box for the majority of packages
- enables full-range QA checking

Cons:
- pre-inherit variable
- some (harmless) false positives on existing packages


Variant 2: distutils_enable_setuptools
======================================
The alternative method is to add another function
to the distutils_enable* series:

distutils_enable_setuptools [-r]

The basic form adds it to BDEPEND, -r B+RDEPEND.  Of course, no dep is
present by default.  The main difference from setting deps explicitly is
that it permits us to do a minimal QA check between pure BDEPEND
and B+RDEPEND for now.

When all ebuilds are migrated from explicit dependencies to this method,
we can also start detecting missing deps completely.  However, that
presumes we require using this function rather than explicit deps.

Pros:
- no pre-inherit variables

Cons:
- only partial QA check possible for the time being
- requires migrating all ebuilds long-term


Variant 3: leave as-is, add minimal install-qa-check.d
======================================================
We can just continue adding deps manually, and add a minimal install-qa-
check.d that greps installed scripts for entry_points usage.  This will
let us detect missing RDEPEND on setuptools but not BDEPEND.

Pros:
- no changes to ebuilds

Cons:
- only partial QA check possible


WDYT?
=====
Both options have their pros and cons.  I think V1 is the best since it
avoids a common mistake, and gives full range QA check.  It also doesn't
interfere with existing deps.  V2 neatly fits into the recent series but
still requires users to remember to call it, and we can't report missing
calls until we clean up all ebuilds.  V3 provides only minimal QA
improvement without changing the eclass.

WDYT?  Do you have any other ideas?

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages

[Joonas Niilola]

[-- Attachment #1.1: Type: text/plain, Size: 5699 bytes --]

Hey,


On 11/25/19 7:38 PM, Michał Górny wrote:
> Hi,
>
> TL;DR: should we depend on setuptools by default?  Alternatively, should
> we add distutils_enable_setuptools API to provide at least partial
> validity checks.
>
>
> The problem
> ===========
> The vast majority of Python packages nowadays uses setuptools as their
> build system.  According to a cheap grep, 1633 out of 2415 packages
> using distutils-r1 depends on it -- and I suspect the vast majority of
> those that do not are simply missing the dependency.

Truthfully I thought distutils already (B)DEPENDed on setuptools, so at
least I've left it out "on purpose". I was recently made aware it
doesn't. No bug reports are made about it, so I think it's safe to
assume setuptools is already present in every system?


>
> Are there valid cases for not using setuptools?  Notably, packages
> needed to bootstrap setuptools aren't using it.  Plus some simple
> packages that really don't need its features.
>
> There are also packages that use setuptools but have distutils fallback.
> We don't like them because switching between build systems involves file
> <-> directory replacement that isn't handled cleanly by our package
> managers.  Therefore, we want to always force one build system in them.
>
> The setuptools dependency is so common it's easy to miss.  Notably, it's
> a prerequisite of specifying package dependencies, so it's normally not
> listed in dependencies.
>
> Finally, while most of the time setuptools is just BDEPEND, there are
> cases when it's RDEPEND as well.  The most common is the use
> of entry_points -- and again, upstreams don't mention it explicitly.
>
> All that considered, I think we should work on providing a better API
> for depending on setuptools, to reduce the number of missing
> dependencies and make it possible to automatically test for them
> (reminder: PMS doesn't permit inspecting *DEPEND).
>
>
> Variant 1: automatic dependency on setuptools
> =============================================
> Basically, we add a new trinary pre-inherit variable:
>
> DISTUTILS_USE_SETUPTOOLS=no
>   -> no deps
> DISTUTILS_USE_SETUPTOOLS=bdepend
>   -> add to BDEPEND (the default)
> DISTUTILS_USE_SETUPTOOLS=rdepend
>   -> add to BDEPEND+RDEPEND
>
> This is roughly 'erring on the safe side'.  The default will work for
> the majority of packages.  We will have to disable it for setuptools
> bootstrap deps, and devs will be able to adjust it to correct values
> as they update ebuilds.  For the time being, existing *DEPEND
> on setuptools will avoid breaking stuff.
>
> This will also enable me to add extra QA checks to esetup.py.  It should
> be able to reasonably detect incorrect value and report it.  This will
> imply some 'false positives' for packages that use the old method of
> specifying setuptools in RDEPEND but that's a minor hassle.
>
> Pros:
> - works out of the box for the majority of packages
> - enables full-range QA checking
>
> Cons:
> - pre-inherit variable
> - some (harmless) false positives on existing packages

I'm a fan of this solution, unless it causes a lot of new CI noise. I
think people are getting fed up with recent changes already, starting to
ignore whatever CI bot says, unless it's fatal.

No harm in double-defining setuptools in BDEPEND right...? (via eclass
and ebuild)


>
>
> Variant 2: distutils_enable_setuptools
> ======================================
> The alternative method is to add another function
> to the distutils_enable* series:
>
> distutils_enable_setuptools [-r]
>
> The basic form adds it to BDEPEND, -r B+RDEPEND.  Of course, no dep is
> present by default.  The main difference from setting deps explicitly is
> that it permits us to do a minimal QA check between pure BDEPEND
> and B+RDEPEND for now.
>
> When all ebuilds are migrated from explicit dependencies to this method,
> we can also start detecting missing deps completely.  However, that
> presumes we require using this function rather than explicit deps.
>
> Pros:
> - no pre-inherit variables
>
> Cons:
> - only partial QA check possible for the time being
> - requires migrating all ebuilds long-term

I don't like this at this point. This would just bring unwanted noise
and lots of editing in ebuilds. V1 and V3 are better IMHO. This could be
implemented in distutils-r2.eclass, though.


>
>
> Variant 3: leave as-is, add minimal install-qa-check.d
> ======================================================
> We can just continue adding deps manually, and add a minimal install-qa-
> check.d that greps installed scripts for entry_points usage.  This will
> let us detect missing RDEPEND on setuptools but not BDEPEND.
>
> Pros:
> - no changes to ebuilds
>
> Cons:
> - only partial QA check possible

The old way, is also good.


>
>
> WDYT?
> =====
> Both options have their pros and cons.  I think V1 is the best since it
> avoids a common mistake, and gives full range QA check.  It also doesn't
> interfere with existing deps.  V2 neatly fits into the recent series but
> still requires users to remember to call it, and we can't report missing
> calls until we clean up all ebuilds.  V3 provides only minimal QA
> improvement without changing the eclass.
>
> WDYT?  Do you have any other ideas?

As I said, I don't even know how one ends up with a system without
setuptools, so I don't view this "superimportant". Still I like your
suggestions 1 & 3 in handling it in future. However if you're going to
implement CI checks with this, I don't believe the timing is right
currently.


-- juippis



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 642 bytes --]

Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages

[Michał Górny]

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

On Mon, 2019-11-25 at 20:39 +0200, Joonas Niilola wrote:
> Hey,
> 
> 
> On 11/25/19 7:38 PM, Michał Górny wrote:
> > Hi,
> > 
> > TL;DR: should we depend on setuptools by default?  Alternatively, should
> > we add distutils_enable_setuptools API to provide at least partial
> > validity checks.
> > 
> > 
> > The problem
> > ===========
> > The vast majority of Python packages nowadays uses setuptools as their
> > build system.  According to a cheap grep, 1633 out of 2415 packages
> > using distutils-r1 depends on it -- and I suspect the vast majority of
> > those that do not are simply missing the dependency.
> 
> Truthfully I thought distutils already (B)DEPENDed on setuptools, so at
> least I've left it out "on purpose". I was recently made aware it
> doesn't. No bug reports are made about it, so I think it's safe to
> assume setuptools is already present in every system?

Yes, we do get bug reports about it occassionally.

> 
> 
> > Are there valid cases for not using setuptools?  Notably, packages
> > needed to bootstrap setuptools aren't using it.  Plus some simple
> > packages that really don't need its features.
> > 
> > There are also packages that use setuptools but have distutils fallback.
> > We don't like them because switching between build systems involves file
> > <-> directory replacement that isn't handled cleanly by our package
> > managers.  Therefore, we want to always force one build system in them.
> > 
> > The setuptools dependency is so common it's easy to miss.  Notably, it's
> > a prerequisite of specifying package dependencies, so it's normally not
> > listed in dependencies.
> > 
> > Finally, while most of the time setuptools is just BDEPEND, there are
> > cases when it's RDEPEND as well.  The most common is the use
> > of entry_points -- and again, upstreams don't mention it explicitly.
> > 
> > All that considered, I think we should work on providing a better API
> > for depending on setuptools, to reduce the number of missing
> > dependencies and make it possible to automatically test for them
> > (reminder: PMS doesn't permit inspecting *DEPEND).
> > 
> > 
> > Variant 1: automatic dependency on setuptools
> > =============================================
> > Basically, we add a new trinary pre-inherit variable:
> > 
> > DISTUTILS_USE_SETUPTOOLS=no
> >   -> no deps
> > DISTUTILS_USE_SETUPTOOLS=bdepend
> >   -> add to BDEPEND (the default)
> > DISTUTILS_USE_SETUPTOOLS=rdepend
> >   -> add to BDEPEND+RDEPEND
> > 
> > This is roughly 'erring on the safe side'.  The default will work for
> > the majority of packages.  We will have to disable it for setuptools
> > bootstrap deps, and devs will be able to adjust it to correct values
> > as they update ebuilds.  For the time being, existing *DEPEND
> > on setuptools will avoid breaking stuff.
> > 
> > This will also enable me to add extra QA checks to esetup.py.  It should
> > be able to reasonably detect incorrect value and report it.  This will
> > imply some 'false positives' for packages that use the old method of
> > specifying setuptools in RDEPEND but that's a minor hassle.
> > 
> > Pros:
> > - works out of the box for the majority of packages
> > - enables full-range QA checking
> > 
> > Cons:
> > - pre-inherit variable
> > - some (harmless) false positives on existing packages
> 
> I'm a fan of this solution, unless it causes a lot of new CI noise. I
> think people are getting fed up with recent changes already, starting to
> ignore whatever CI bot says, unless it's fatal.
> 
> No harm in double-defining setuptools in BDEPEND right...? (via eclass
> and ebuild)

Yes, double defining is fine.

> 
> 
> > 
> > Variant 2: distutils_enable_setuptools
> > ======================================
> > The alternative method is to add another function
> > to the distutils_enable* series:
> > 
> > distutils_enable_setuptools [-r]
> > 
> > The basic form adds it to BDEPEND, -r B+RDEPEND.  Of course, no dep is
> > present by default.  The main difference from setting deps explicitly is
> > that it permits us to do a minimal QA check between pure BDEPEND
> > and B+RDEPEND for now.
> > 
> > When all ebuilds are migrated from explicit dependencies to this method,
> > we can also start detecting missing deps completely.  However, that
> > presumes we require using this function rather than explicit deps.
> > 
> > Pros:
> > - no pre-inherit variables
> > 
> > Cons:
> > - only partial QA check possible for the time being
> > - requires migrating all ebuilds long-term
> 
> I don't like this at this point. This would just bring unwanted noise
> and lots of editing in ebuilds. V1 and V3 are better IMHO. This could be
> implemented in distutils-r2.eclass, though.
> 
> 
> > 
> > Variant 3: leave as-is, add minimal install-qa-check.d
> > ======================================================
> > We can just continue adding deps manually, and add a minimal install-qa-
> > check.d that greps installed scripts for entry_points usage.  This will
> > let us detect missing RDEPEND on setuptools but not BDEPEND.
> > 
> > Pros:
> > - no changes to ebuilds
> > 
> > Cons:
> > - only partial QA check possible
> 
> The old way, is also good.
> 
> 
> > 
> > WDYT?
> > =====
> > Both options have their pros and cons.  I think V1 is the best since it
> > avoids a common mistake, and gives full range QA check.  It also doesn't
> > interfere with existing deps.  V2 neatly fits into the recent series but
> > still requires users to remember to call it, and we can't report missing
> > calls until we clean up all ebuilds.  V3 provides only minimal QA
> > improvement without changing the eclass.
> > 
> > WDYT?  Do you have any other ideas?
> 
> As I said, I don't even know how one ends up with a system without
> setuptools, so I don't view this "superimportant". Still I like your
> suggestions 1 & 3 in handling it in future. However if you're going to
> implement CI checks with this, I don't believe the timing is right
> currently.
> 

1. If you have no packages with RDEPEND on setuptools and some --with-
bdeps setting, --depclean can kill it.

2. Early after install.

3. On tinderbox, if no dep pulled it in.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages

[Jason Zaman]

On Mon, Nov 25, 2019 at 06:38:47PM +0100, Michał Górny wrote:
> Hi,
> 
> TL;DR: should we depend on setuptools by default?  Alternatively, should
> we add distutils_enable_setuptools API to provide at least partial
> validity checks.
> 
> 
> Variant 1: automatic dependency on setuptools
> =============================================
> Basically, we add a new trinary pre-inherit variable:
> 
> DISTUTILS_USE_SETUPTOOLS=no
>   -> no deps
> DISTUTILS_USE_SETUPTOOLS=bdepend
>   -> add to BDEPEND (the default)
> DISTUTILS_USE_SETUPTOOLS=rdepend
>   -> add to BDEPEND+RDEPEND
> 
> This is roughly 'erring on the safe side'.  The default will work for
> the majority of packages.  We will have to disable it for setuptools
> bootstrap deps, and devs will be able to adjust it to correct values
> as they update ebuilds.  For the time being, existing *DEPEND
> on setuptools will avoid breaking stuff.
> 
> This will also enable me to add extra QA checks to esetup.py.  It should
> be able to reasonably detect incorrect value and report it.  This will
> imply some 'false positives' for packages that use the old method of
> specifying setuptools in RDEPEND but that's a minor hassle.
> 
> Pros:
> - works out of the box for the majority of packages
> - enables full-range QA checking
> 
> Cons:
> - pre-inherit variable
> - some (harmless) false positives on existing packages
> 

I like variant 1 most since in almost all cases it'll be less work in
the ebuilds. What about distutils_optional tho? In tensorflow I have all
the python support behind USE="python" and guard all the deps. In the
optional case is there any way for this to work other than just setting
it to no and doing it manually?
I assume if i set it to no and make it optional then the esetup.py
checks wouldnt happen which isnt as nice.

-- Jason

Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages

[Michał Górny]

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

On Tue, 2019-11-26 at 21:30 +0800, Jason Zaman wrote:
> On Mon, Nov 25, 2019 at 06:38:47PM +0100, Michał Górny wrote:
> > Hi,
> > 
> > TL;DR: should we depend on setuptools by default?  Alternatively, should
> > we add distutils_enable_setuptools API to provide at least partial
> > validity checks.
> > 
> > 
> > Variant 1: automatic dependency on setuptools
> > =============================================
> > Basically, we add a new trinary pre-inherit variable:
> > 
> > DISTUTILS_USE_SETUPTOOLS=no
> >   -> no deps
> > DISTUTILS_USE_SETUPTOOLS=bdepend
> >   -> add to BDEPEND (the default)
> > DISTUTILS_USE_SETUPTOOLS=rdepend
> >   -> add to BDEPEND+RDEPEND
> > 
> > This is roughly 'erring on the safe side'.  The default will work for
> > the majority of packages.  We will have to disable it for setuptools
> > bootstrap deps, and devs will be able to adjust it to correct values
> > as they update ebuilds.  For the time being, existing *DEPEND
> > on setuptools will avoid breaking stuff.
> > 
> > This will also enable me to add extra QA checks to esetup.py.  It should
> > be able to reasonably detect incorrect value and report it.  This will
> > imply some 'false positives' for packages that use the old method of
> > specifying setuptools in RDEPEND but that's a minor hassle.
> > 
> > Pros:
> > - works out of the box for the majority of packages
> > - enables full-range QA checking
> > 
> > Cons:
> > - pre-inherit variable
> > - some (harmless) false positives on existing packages
> > 
> 
> I like variant 1 most since in almost all cases it'll be less work in
> the ebuilds. What about distutils_optional tho? In tensorflow I have all
> the python support behind USE="python" and guard all the deps. In the
> optional case is there any way for this to work other than just setting
> it to no and doing it manually?
> I assume if i set it to no and make it optional then the esetup.py
> checks wouldnt happen which isnt as nice.

That's a very good question, and I'm afraid I don't have a good answer. 
To be honest, I don't see how we could solve this.

Since you need to add the appropriate variables to BDEPEND and RDEPEND
yourself, there's little purpose in trying to introduce some kind of
indirection for this -- it may detect that you've declared the wrong
kind of dep but it won't detect if you used the helper variables
correctly, so we're back to square one.

I guess the only reasonable thing to do is to ignore it entirely for
this use case, and rely on the developer doing things right.  Hopefully,
FWICS it's just 43 packages at the moment, so this wouldn't be that bad.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages

[Jason Zaman]

On Tue, Nov 26, 2019 at 04:29:28PM +0100, Michał Górny wrote:
> On Tue, 2019-11-26 at 21:30 +0800, Jason Zaman wrote:
> > On Mon, Nov 25, 2019 at 06:38:47PM +0100, Michał Górny wrote:
> > > Hi,
> > > 
> > > TL;DR: should we depend on setuptools by default?  Alternatively, should
> > > we add distutils_enable_setuptools API to provide at least partial
> > > validity checks.
> > > 
> > > 
> > > Variant 1: automatic dependency on setuptools
> > > =============================================
> > > Basically, we add a new trinary pre-inherit variable:
> > > 
> > > DISTUTILS_USE_SETUPTOOLS=no
> > >   -> no deps
> > > DISTUTILS_USE_SETUPTOOLS=bdepend
> > >   -> add to BDEPEND (the default)
> > > DISTUTILS_USE_SETUPTOOLS=rdepend
> > >   -> add to BDEPEND+RDEPEND
> > > 
> > > This is roughly 'erring on the safe side'.  The default will work for
> > > the majority of packages.  We will have to disable it for setuptools
> > > bootstrap deps, and devs will be able to adjust it to correct values
> > > as they update ebuilds.  For the time being, existing *DEPEND
> > > on setuptools will avoid breaking stuff.
> > > 
> > > This will also enable me to add extra QA checks to esetup.py.  It should
> > > be able to reasonably detect incorrect value and report it.  This will
> > > imply some 'false positives' for packages that use the old method of
> > > specifying setuptools in RDEPEND but that's a minor hassle.
> > > 
> > > Pros:
> > > - works out of the box for the majority of packages
> > > - enables full-range QA checking
> > > 
> > > Cons:
> > > - pre-inherit variable
> > > - some (harmless) false positives on existing packages
> > > 
> > 
> > I like variant 1 most since in almost all cases it'll be less work in
> > the ebuilds. What about distutils_optional tho? In tensorflow I have all
> > the python support behind USE="python" and guard all the deps. In the
> > optional case is there any way for this to work other than just setting
> > it to no and doing it manually?
> > I assume if i set it to no and make it optional then the esetup.py
> > checks wouldnt happen which isnt as nice.
> 
> That's a very good question, and I'm afraid I don't have a good answer. 
> To be honest, I don't see how we could solve this.
> 
> Since you need to add the appropriate variables to BDEPEND and RDEPEND
> yourself, there's little purpose in trying to introduce some kind of
> indirection for this -- it may detect that you've declared the wrong
> kind of dep but it won't detect if you used the helper variables
> correctly, so we're back to square one.
> 
> I guess the only reasonable thing to do is to ignore it entirely for
> this use case, and rely on the developer doing things right.  Hopefully,
> FWICS it's just 43 packages at the moment, so this wouldn't be that bad.

I suspected this would be the case. I think its fine to not do it in the
optional case and just update the docs to be really clear exactly what
and how the ebuild must do is good enough. 43 packages out of the many
thousand that use distutils-r1 seems like worrying about it isnt worth
it yeah.

-- Jason
> 
> -- 
> Best regards,
> Michał Górny
> 

Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages

[Michał Górny]

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

On Tue, 2019-11-26 at 21:30 +0800, Jason Zaman wrote:
> On Mon, Nov 25, 2019 at 06:38:47PM +0100, Michał Górny wrote:
> > Hi,
> > 
> > TL;DR: should we depend on setuptools by default?  Alternatively, should
> > we add distutils_enable_setuptools API to provide at least partial
> > validity checks.
> > 
> > 
> > Variant 1: automatic dependency on setuptools
> > =============================================
> > Basically, we add a new trinary pre-inherit variable:
> > 
> > DISTUTILS_USE_SETUPTOOLS=no
> >   -> no deps
> > DISTUTILS_USE_SETUPTOOLS=bdepend
> >   -> add to BDEPEND (the default)
> > DISTUTILS_USE_SETUPTOOLS=rdepend
> >   -> add to BDEPEND+RDEPEND
> > 
> > This is roughly 'erring on the safe side'.  The default will work for
> > the majority of packages.  We will have to disable it for setuptools
> > bootstrap deps, and devs will be able to adjust it to correct values
> > as they update ebuilds.  For the time being, existing *DEPEND
> > on setuptools will avoid breaking stuff.
> > 
> > This will also enable me to add extra QA checks to esetup.py.  It should
> > be able to reasonably detect incorrect value and report it.  This will
> > imply some 'false positives' for packages that use the old method of
> > specifying setuptools in RDEPEND but that's a minor hassle.
> > 
> > Pros:
> > - works out of the box for the majority of packages
> > - enables full-range QA checking
> > 
> > Cons:
> > - pre-inherit variable
> > - some (harmless) false positives on existing packages
> > 
> 
> I like variant 1 most since in almost all cases it'll be less work in
> the ebuilds. What about distutils_optional tho? In tensorflow I have all
> the python support behind USE="python" and guard all the deps. In the
> optional case is there any way for this to work other than just setting
> it to no and doing it manually?
> I assume if i set it to no and make it optional then the esetup.py
> checks wouldnt happen which isnt as nice.
> 

Hmm, I gave it some more thought and I have an idea.

We could introduce new ${DISTUTILS_RDEPEND} and ${DISTUTILS_DEPEND}
variables, and deprecate (as a general rule) direct ${PYTHON_DEPS} usage
in favor of it.  Then we could easily inject setuptools into it.

Bad news is that it will make it incorrect to do BDEPEND=${RDEPEND}
in general, even when DISTUTILS_RDEPEND==DISTUTILS_DEPEND.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]