1 |
Hello, |
2 |
|
3 |
Some aspects of the current design of python-single-r1 are gross hack. |
4 |
I'd like to discuss potential alternatives to them. |
5 |
|
6 |
|
7 |
Preamble |
8 |
======== |
9 |
For the purpose of this mail, let's establish two terms. |
10 |
|
11 |
'Single' will refer to packages allowing the user to select 1 out of N |
12 |
supported Python implementations. This generally means programs linking |
13 |
to libpython, foreign build systems and end-user apps where installing |
14 |
multiple copies of the code makes no sense. Those are the packages |
15 |
using python-single-r1. |
16 |
|
17 |
'Multi' will refer to packages allowing the user to select M out of N |
18 |
supported Python implementations. This generally means ebuilds for |
19 |
Python packages (modules, extensions). Those are the packages using |
20 |
python-r1 (usually via distutils-r1). |
21 |
|
22 |
'Single' packages can PYTHON_USEDEP-end either on other 'single' |
23 |
or on 'multi' packages. However, 'multi' packages can only |
24 |
PYTHON_USEDEP-end on other 'multi' packages (because 'single' wouldn't |
25 |
ever be able to satisfy >1 impl). |
26 |
|
27 |
|
28 |
Current status |
29 |
============== |
30 |
Currently, 'single' packages use two sets of USE flags: PYTHON_TARGETS |
31 |
and PYTHON_SINGLE_TARGET. The latter is used to select |
32 |
the implementation used, and the former is used only for technical |
33 |
reasons. Selected PST is required to be also enabled in PT. |
34 |
|
35 |
All dependencies enforce both PST and PT match. The PYTHON_USEDEP is |
36 |
generally a giant hack that's meant to work both for depending |
37 |
on 'single' and 'multi' packages. I'm not convinced this was the best |
38 |
choice anymore. |
39 |
|
40 |
In single-to-single deps, PYTHON_USEDEP enforces both PST and PT flags |
41 |
to match. This means that if two packages have matching PST but for |
42 |
some reason were built with different PT, users end up having to switch |
43 |
PT and rebuild the package without any real change. |
44 |
|
45 |
In single-to-multi deps, PYTHON_USEDEP enforces PT flags. For this |
46 |
reason, we need to enforce that selected PST is always present in PT, |
47 |
and users always have to put both flags in package.use. |
48 |
|
49 |
There's also a gross hack in PYTHON_USEDEP in 'multi' packages that |
50 |
means to prevent multi-to-single deps. However, the dep mismatch it |
51 |
causes is not very readable. |
52 |
|
53 |
|
54 |
Alternative 1: PYTHON_TARGETS only |
55 |
================================== |
56 |
The first alternative I'd like to explore is removing |
57 |
PYTHON_SINGLE_TARGET flags. Why were they added in the first place? |
58 |
The primary goal was to be able to set PT to 2.7+3.x without requiring |
59 |
people to adjust flags for every 'single' package out there. Plus, it |
60 |
turned out very convenient for Python team members who want to enable |
61 |
all PT but obviously can't do the same for PST. |
62 |
|
63 |
Originally I brought this proposal in context of automated REQUIRED_USE |
64 |
conflict resolution. However, that was rejected by the Council. Still, |
65 |
it may start making sense again in the near future when we start |
66 |
removing py2.7 and pypy2.7 support. If we can limit PT to one |
67 |
implementation, and handle the remaining packages via IUSE defaults |
68 |
and package.use, this may just work. |
69 |
|
70 |
The inconvenience to people enabling multiple PT will remain though. |
71 |
|
72 |
|
73 |
Alternative 2: new dependency API |
74 |
================================= |
75 |
If PST is going to stay, we may look into removing PT from 'single' |
76 |
packages instead. The idea is to provide new method of generating |
77 |
cross-package deps that doesn't require fake flags. |
78 |
|
79 |
PYTHON_USEDEP would continue working through a transitional period. |
80 |
When it's entirely gone, we can remove PYTHON_TARGETS from 'single' |
81 |
packages. |
82 |
|
83 |
Single-to-single deps would switch to PYTHON_SINGLE_USEDEP, that only |
84 |
enforces PST and disregards PT entirely. |
85 |
|
86 |
Single-to-multi deps would have to use a new generator function, |
87 |
$(python_gen_multi_dep ...) that would create appropriate USE-mapping |
88 |
from PST to PT. |
89 |
|
90 |
Example ebuild would have: |
91 |
|
92 |
RDEPEND="app-foo/singlepkg[${PYTHON_SINGLE_USEDEP}] |
93 |
$(python_gen_multi_dep ' |
94 |
dev-python/foo[${PYTHON_USEDEP}] |
95 |
dev-python/bar[${PYTHON_USEDEP}] |
96 |
')" |
97 |
|
98 |
This will generate something like: |
99 |
|
100 |
pst_python2_7? ( |
101 |
dev-python/foo[pt_python2_7(-)] |
102 |
dev-python/bar[pt_python2_7(-)] |
103 |
) |
104 |
pst_python3_7? ( |
105 |
dev-python/foo[pt_python3_7(-)] |
106 |
dev-python/bar[pt_python3_7(-)] |
107 |
) |
108 |
|
109 |
|
110 |
Your opinions |
111 |
============= |
112 |
So, WDYT? Do you think this approach is worthwhile? Do you see other |
113 |
options? |
114 |
|
115 |
|
116 |
-- |
117 |
Best regards, |
118 |
Michał Górny |