Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages
Date: Tue, 26 Nov 2019 15:29:38
Message-Id: abf3fda29f258336f48c61258af7133355bbcb48.camel@gentoo.org
In Reply to: Re: [gentoo-dev] [RFC] dev-python/setuptools deps in distutils-r1 packages by Jason Zaman
1 On Tue, 2019-11-26 at 21:30 +0800, Jason Zaman wrote:
2 > On Mon, Nov 25, 2019 at 06:38:47PM +0100, Michał Górny wrote:
3 > > Hi,
4 > >
5 > > TL;DR: should we depend on setuptools by default? Alternatively, should
6 > > we add distutils_enable_setuptools API to provide at least partial
7 > > validity checks.
8 > >
9 > >
10 > > Variant 1: automatic dependency on setuptools
11 > > =============================================
12 > > Basically, we add a new trinary pre-inherit variable:
13 > >
14 > > DISTUTILS_USE_SETUPTOOLS=no
15 > > -> no deps
16 > > DISTUTILS_USE_SETUPTOOLS=bdepend
17 > > -> add to BDEPEND (the default)
18 > > DISTUTILS_USE_SETUPTOOLS=rdepend
19 > > -> add to BDEPEND+RDEPEND
20 > >
21 > > This is roughly 'erring on the safe side'. The default will work for
22 > > the majority of packages. We will have to disable it for setuptools
23 > > bootstrap deps, and devs will be able to adjust it to correct values
24 > > as they update ebuilds. For the time being, existing *DEPEND
25 > > on setuptools will avoid breaking stuff.
26 > >
27 > > This will also enable me to add extra QA checks to esetup.py. It should
28 > > be able to reasonably detect incorrect value and report it. This will
29 > > imply some 'false positives' for packages that use the old method of
30 > > specifying setuptools in RDEPEND but that's a minor hassle.
31 > >
32 > > Pros:
33 > > - works out of the box for the majority of packages
34 > > - enables full-range QA checking
35 > >
36 > > Cons:
37 > > - pre-inherit variable
38 > > - some (harmless) false positives on existing packages
39 > >
40 >
41 > I like variant 1 most since in almost all cases it'll be less work in
42 > the ebuilds. What about distutils_optional tho? In tensorflow I have all
43 > the python support behind USE="python" and guard all the deps. In the
44 > optional case is there any way for this to work other than just setting
45 > it to no and doing it manually?
46 > I assume if i set it to no and make it optional then the esetup.py
47 > checks wouldnt happen which isnt as nice.
48
49 That's a very good question, and I'm afraid I don't have a good answer.
50 To be honest, I don't see how we could solve this.
51
52 Since you need to add the appropriate variables to BDEPEND and RDEPEND
53 yourself, there's little purpose in trying to introduce some kind of
54 indirection for this -- it may detect that you've declared the wrong
55 kind of dep but it won't detect if you used the helper variables
56 correctly, so we're back to square one.
57
58 I guess the only reasonable thing to do is to ignore it entirely for
59 this use case, and rely on the developer doing things right. Hopefully,
60 FWICS it's just 43 packages at the moment, so this wouldn't be that bad.
61
62 --
63 Best regards,
64 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies