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
Michał Górny (he/they) ∞🙀🚂🐧 /
npub1r9…t4ppx
2024-02-27 08:14:59
Author Public Key
npub1r9jmk6t0ape7t9ddfv5nrrsh87pluzxtepzjqu93sctkkurun0wqft4ppxSeen on
wss://relay.nostr.bandPublished at
2024-02-27 08:14:59Event JSON
{
"id": "cf9af3a66e4f5d3a4f483b1c68fc2682243979bf68ba6914fa3a26d52b3032b1",
"pubkey": "1965bb696fe873e595ad4b29318e173f83fe08cbc8452070b186176b707c9bdc",
"created_at": 1709021699,
"kind": 1,
"tags": [
[
"t",
"gentoo"
],
[
"t",
"python"
],
[
"proxy",
"https://social.treehouse.systems/users/mgorny/statuses/112002446115157924",
"activitypub"
]
],
"content": "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.\n\n#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).\n\nThe 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.\n\nIn 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!\n\nMigration 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.\n\nAfter 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`.\n\nhttps://bugs.gentoo.org/489440#c20",
"sig": "82ea044dd0e0014e326a003598f423f46f50be995affa01c261c883351bd68b930bb86d95dfddc6eff9cfb51eaefddc05d8b45884486fbe816d244486e8052fb"
}