Michał Górny (he/they) ∞🙀🚂🐧 on Nostr: If you were even wondering why #Gentoo python-exec is sitting in dev-lang/ rather ...
If you were even wondering why #Gentoo python-exec is sitting in dev-lang/ rather than dev-python/, that's actually a curious story of a hack.
#Python script wrapping dates back to the original python.eclass. The idea was sound: you'd rename scripts installed by Python packages to "foo-2.6", "foo-3.1", and then install a new wrapper that selects one of these versions. If this may sound unnecessary, remember that scripts need to be run with a Python version that has all its dependencies installed, and that different scripts could technically be installed for different versions (especially in the early Python 3 era, when using 2to3 was not uncommon).
The first version of dev-python/python-exec built on that concept, optimizing it in a few ways. It would install a shared wrapper as a separate package and use symlinks, whereas the old wrappers would be installed separately by every package. It would introduce a C executable to remove the overhead of starting a Python interpreter to determine which interpreter to actually start. However, it did copy the idea of suffixing scripts.
In the long run, this turned out to be a bad idea. Some scripts expected specific names, and we'd ended up hacking and patching things around. So I've made python-exec 2 that used a slightly different approach, and rather than renaming scripts, it moved them into a per-interpreter directory. This not only preserved the basename but let us make things simpler — we could just override the script install directory rather than having to rename stuff!
Migration was the problem. Two different approaches meant that packages built against python-exec:0 would have to continue depending on it. Originally, I've added a `:=` dep to the eclass but this couldn't solve the problem for packages already installed, and Portage ended up removing old python-exec. It wasn't good.
After some tinkering, I've figured out that the best approach is to add both slots as a new package, have the eclass depend on it with `:=` operator going forward and have the old `dev-python/python-exec` pull both slots for compatibility. This is what gave birth to `dev-lang/python-exec`.
https://bugs.gentoo.org/489440#c20
#Python script wrapping dates back to the original python.eclass. The idea was sound: you'd rename scripts installed by Python packages to "foo-2.6", "foo-3.1", and then install a new wrapper that selects one of these versions. If this may sound unnecessary, remember that scripts need to be run with a Python version that has all its dependencies installed, and that different scripts could technically be installed for different versions (especially in the early Python 3 era, when using 2to3 was not uncommon).
The first version of dev-python/python-exec built on that concept, optimizing it in a few ways. It would install a shared wrapper as a separate package and use symlinks, whereas the old wrappers would be installed separately by every package. It would introduce a C executable to remove the overhead of starting a Python interpreter to determine which interpreter to actually start. However, it did copy the idea of suffixing scripts.
In the long run, this turned out to be a bad idea. Some scripts expected specific names, and we'd ended up hacking and patching things around. So I've made python-exec 2 that used a slightly different approach, and rather than renaming scripts, it moved them into a per-interpreter directory. This not only preserved the basename but let us make things simpler — we could just override the script install directory rather than having to rename stuff!
Migration was the problem. Two different approaches meant that packages built against python-exec:0 would have to continue depending on it. Originally, I've added a `:=` dep to the eclass but this couldn't solve the problem for packages already installed, and Portage ended up removing old python-exec. It wasn't good.
After some tinkering, I've figured out that the best approach is to add both slots as a new package, have the eclass depend on it with `:=` operator going forward and have the old `dev-python/python-exec` pull both slots for compatibility. This is what gave birth to `dev-lang/python-exec`.
https://bugs.gentoo.org/489440#c20