| 1 |
Hello, |
| 2 |
|
| 3 |
After starting to deploy python-r1 on packages supporting multiple |
| 4 |
Python implementations, I believe it is time to start thinking about |
| 5 |
those packages which don't support that. Firstly, I would like to gain |
| 6 |
a general feedback/ideas on the possible solutions, without getting too |
| 7 |
deep into the technical details of it. |
| 8 |
|
| 9 |
As far as I can think, we have the following possibilities: |
| 10 |
|
| 11 |
|
| 12 |
1) Assume that installing stuff for a single Python implementation is |
| 13 |
deprecated and let the packages rot with the old eclass. |
| 14 |
|
| 15 |
It is probably the simplest solution (i.e. not doing anything to |
| 16 |
address the issue) but truth be told, I doubt this will actually work. |
| 17 |
People will just keep using the old eclass which doesn't really do much |
| 18 |
good for those packages... |
| 19 |
|
| 20 |
And even if some people will actually start supporting multiple |
| 21 |
implementations... that may be even worse. Just look at dev-libs/boost |
| 22 |
to see what I mean. |
| 23 |
|
| 24 |
|
| 25 |
2) Use a xor-type REQUIRED_USE for those packages. |
| 26 |
|
| 27 |
Put the whole set of PYTHON_TARGETS but add a REQUIRED_USE='^^ ( ... )' |
| 28 |
for them, effectively requesting only a single implementation being |
| 29 |
enabled. |
| 30 |
|
| 31 |
I believe that this is quite a good solution, at least from |
| 32 |
the dependency point of view. We clearly express which Python |
| 33 |
implementations are supported by a particular package and which one was |
| 34 |
enabled. We can express cross-package dependencies cleanly. |
| 35 |
|
| 36 |
The problem lies in user-friendliness. Although with the current |
| 37 |
default (python2_7 only) it wouldn't cause any trouble, whenever user |
| 38 |
enables more than a single implementation, every single-implementation |
| 39 |
package will require package.use adjustment. This will become an even |
| 40 |
more widespread issue when we decide to re-enable Python 3. |
| 41 |
|
| 42 |
To be honest, I don't see any good way around that. |
| 43 |
|
| 44 |
|
| 45 |
3) Use implicit implementation selection (like python.eclass). |
| 46 |
|
| 47 |
Well, as some say, this is a very good solution since it's well tested. |
| 48 |
Its limitations and brokenness are obvious. Just I doubt it is really |
| 49 |
worth the effort to write something that bad. |
| 50 |
|
| 51 |
The main problem here is that the chosen Python implementation is |
| 52 |
implicit. Binary packages don't express it. Cross-package dependencies |
| 53 |
don't express it. User changes the implementation, stuff breaks |
| 54 |
silently and you end up with some kind of python-updater (why a tool |
| 55 |
to fix breakage is called 'updater'?!). |
| 56 |
|
| 57 |
|
| 58 |
Do you have any more ideas? Opinions? |
| 59 |
|
| 60 |
-- |
| 61 |
Best regards, |
| 62 |
Michał Górny |
Archives