1 |
On Thu, 2020-03-26 at 14:13 -0500, William Hubbs wrote: |
2 |
> There are situations in which downstream overlays need to have versions |
3 |
> of python which Gentoo no longer supports in the tree. |
4 |
> |
5 |
> Currently, the only way to do this is for the overlay author to fork |
6 |
> python-utils-r1.eclass. This is highly undesirable since it creates a |
7 |
> very significant maintenance burden for the overlay author. |
8 |
> |
9 |
> There are a couple of things we can do upstream to make this easier, and |
10 |
> I think we should do one of them. |
11 |
> |
12 |
> The simplest way would be to apply the following patch. |
13 |
> In this situation, all the overlay author |
14 |
> would have to do is adjust the PYTHON_COMPAT_ALLOW_EXTRA_IMPLS variable. |
15 |
> |
16 |
> The other option would be to move _PYTHON_ALL_IMPLS and the |
17 |
> implementation of _python_impl_supported to a separate eclass, e.g. |
18 |
> python-impls-r1.eclass. This eclass could be forked freely downstream |
19 |
> without worrying about the other python eclasses. |
20 |
> I will volunteer to do the legwork for this option if we do not like the |
21 |
> first one. |
22 |
> |
23 |
> I would advocate the first option however since no one has to fork |
24 |
> anything. |
25 |
> |
26 |
> Thoughts? |
27 |
> |
28 |
> William |
29 |
> |
30 |
> William Hubbs (1): |
31 |
> python.eclass: add PYTHON_COMPAT_ALLOW_EXTRA_IMPLS |
32 |
> |
33 |
> eclass/python-utils-r1.eclass | 2 ++ |
34 |
> 1 file changed, 2 insertions(+) |
35 |
> |
36 |
|
37 |
How do you prevent some extra clever Gentoo developer from doing the following |
38 |
in ::gentoo |
39 |
|
40 |
dev-python/foo/foo-1.ebuild: |
41 |
|
42 |
# don't have the time to port this right now, patches welcome |
43 |
PYTHON_COMPAT_ALLOW_EXTRA_IMPLS=( python3_4 ) |
44 |
PYTHON_COMPAT=( python3_4 ) |
45 |
inherit distutils-r1 |
46 |
|
47 |
Furthermore, defining PYTHON_COMPAT_ALLOW_EXTRA_IMPLS is going to break metadata |
48 |
invariance, causing tons of cache mis-hits. How do you prevent that? |
49 |
|
50 |
In addition, this will very quickly cause whatever overlay this is being used in |
51 |
to become invalid. Imagine I have dev-python/foo::gentoo that supports python |
52 |
3.4 and 3.5 and have dev-python/bar::sony supporting 3.4 and 3.5 sitting in a |
53 |
hypothetical overlay, which depends on dev-python/foo::gentoo. Now we remove |
54 |
python 3.4 from ::gentoo in python-utils-r1, and one week later we remove |
55 |
python3.4 from dev-python/foo::gentoo's PYTHON_COMPAT. Now your dev- |
56 |
python/bar::sony in conjunction with PYTHON_COMPAT_ALLOW_EXTRA_IMPLS has an |
57 |
invalid depgraph. How do you wish to resolve this? |
58 |
|
59 |
I feel like keeping up with ::gentoo is ultimately the better strategy than |
60 |
trying to add backdoors to eclasses because some overlays are somewhat behind. |
61 |
|
62 |
Regards |
63 |
David |