| 1 |
Hello, everyone. |
| 2 |
|
| 3 |
With IPython dropping support for Python2 in the master branch, we're |
| 4 |
facing an entirely new class of issues. This effectively blocked us |
| 5 |
from unmasking the new version, as it would unleash a certain level of |
| 6 |
mayhem on our user's systems. What's worst is that we're probably going |
| 7 |
to be alone with the problem. |
| 8 |
|
| 9 |
|
| 10 |
What's the problem, exactly? |
| 11 |
============================ |
| 12 |
|
| 13 |
Well, where to start... The problem start with us trying hard to |
| 14 |
support multiple Python implementations with weak tooling. One of |
| 15 |
the basic limitations of this is that normally we can only install |
| 16 |
a single version of a Python package, and this version is installed |
| 17 |
for a chosen set of Python implementations. |
| 18 |
|
| 19 |
Now, IPython is now split upstream into two branches: 5 and 6. The old |
| 20 |
branch 5 supports py2+py3 which is good. The new branch 6 supports py3 |
| 21 |
only. This means that any IPython revdep that requires py2 needs to |
| 22 |
force the old branch. |
| 23 |
|
| 24 |
This wouldn't be so bad if not the fact that 1) IPython has a lot of |
| 25 |
revdeps (including indirect revdeps), and 2) for practical reasons, we |
| 26 |
default to enabling py2+py3 everywhere. This means that even if user |
| 27 |
does not need py2-ipython at all, some packages will most likely pull it |
| 28 |
in anyway and prevent him from upgrading to ipy-6. |
| 29 |
|
| 30 |
What's even worse is that Portage backtracking-based dependency |
| 31 |
resolution is very slow in dealing with this. So effectively all of our |
| 32 |
users are going to be subject to even more slowdown in Portage |
| 33 |
operations. |
| 34 |
|
| 35 |
|
| 36 |
Why others don't hit it? |
| 37 |
======================== |
| 38 |
|
| 39 |
The answer is simple: because they have lower goals and/or more flexible |
| 40 |
tooling. |
| 41 |
|
| 42 |
Pip-based solutions generally don't care beyond a single implementation. |
| 43 |
If the particular environment is based on python3, it will just install |
| 44 |
newer IPython. If it is based on python2, it will install the old one. |
| 45 |
|
| 46 |
Other distros don't care beyond supporting two Python implementations |
| 47 |
simultaneously. As such, instead of trying hard to support N |
| 48 |
implementations, they build their packages in py2 & py3 variants, |
| 49 |
and are done with it. In their case, the py2 ipython package is just |
| 50 |
going to be older. |
| 51 |
|
| 52 |
|
| 53 |
What can we do to solve it? |
| 54 |
=========================== |
| 55 |
|
| 56 |
a) Do nothing and hope upstreams solve it at some point. I don't think |
| 57 |
this is acceptable because Portage's slowdown is going to be |
| 58 |
significant. |
| 59 |
|
| 60 |
b) Start dropping py2 from packages. Sadly, this is hard because we're |
| 61 |
talking about huge reverse dependency graph, and I'm pretty sure some of |
| 62 |
our users need those packages w/ py2 support. |
| 63 |
|
| 64 |
c) Slot IPython? That's probably the least intrusive option, though |
| 65 |
ugly as hell, and I'm not sure if it's not going to impact dep |
| 66 |
calculation severely anyway. We'd have a :5 slot that supports py2 |
| 67 |
only, and :0 slot that supports py3 only. Dependencies will be tricky, |
| 68 |
life's going to be hard but maybe things will work. |
| 69 |
|
| 70 |
Any other options? |
| 71 |
|
| 72 |
|
| 73 |
Unless someone has a better idea, I think a combined b+c approach might |
| 74 |
be the way to go. That is: |
| 75 |
|
| 76 |
1. slot IPython as described above. |
| 77 |
|
| 78 |
2. update py2+py3 revdeps to use proper cond-dep for slotted version. |
| 79 |
|
| 80 |
3. slowly drop py2 from revdeps whenever possible. |
| 81 |
|
| 82 |
-- |
| 83 |
Best regards, |
| 84 |
Michał Górny |
Archives