Hello, everyone. With IPython dropping support for Python2 in the master branch, we're facing an entirely new class of issues. This effectively blocked us from unmasking the new version, as it would unleash a certain level of mayhem on our user's systems. What's worst is that we're probably going to be alone with the problem.
What's the problem, exactly? ============================ Well, where to start... The problem start with us trying hard to support multiple Python implementations with weak tooling. One of the basic limitations of this is that normally we can only install a single version of a Python package, and this version is installed for a chosen set of Python implementations. Now, IPython is now split upstream into two branches: 5 and 6. The old branch 5 supports py2+py3 which is good. The new branch 6 supports py3 only. This means that any IPython revdep that requires py2 needs to force the old branch. This wouldn't be so bad if not the fact that 1) IPython has a lot of revdeps (including indirect revdeps), and 2) for practical reasons, we default to enabling py2+py3 everywhere. This means that even if user does not need py2-ipython at all, some packages will most likely pull it in anyway and prevent him from upgrading to ipy-6. What's even worse is that Portage backtracking-based dependency resolution is very slow in dealing with this. So effectively all of our users are going to be subject to even more slowdown in Portage operations. Why others don't hit it? ======================== The answer is simple: because they have lower goals and/or more flexible tooling. Pip-based solutions generally don't care beyond a single implementation. If the particular environment is based on python3, it will just install newer IPython. If it is based on python2, it will install the old one. Other distros don't care beyond supporting two Python implementations simultaneously. As such, instead of trying hard to support N implementations, they build their packages in py2 & py3 variants, and are done with it. In their case, the py2 ipython package is just going to be older. What can we do to solve it? =========================== a) Do nothing and hope upstreams solve it at some point. I don't think this is acceptable because Portage's slowdown is going to be significant. b) Start dropping py2 from packages. Sadly, this is hard because we're talking about huge reverse dependency graph, and I'm pretty sure some of our users need those packages w/ py2 support. c) Slot IPython? That's probably the least intrusive option, though ugly as hell, and I'm not sure if it's not going to impact dep calculation severely anyway. We'd have a :5 slot that supports py2 only, and :0 slot that supports py3 only. Dependencies will be tricky, life's going to be hard but maybe things will work. Any other options? Unless someone has a better idea, I think a combined b+c approach might be the way to go. That is: 1. slot IPython as described above. 2. update py2+py3 revdeps to use proper cond-dep for slotted version. 3. slowly drop py2 from revdeps whenever possible. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
