| Summary: | eselect python vs. dev-lang/python:SLOTs vs. PYTHON_TARGETS_* | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Stéphane Veyret <sveyret> |
| Component: | Profiles | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | ionen, kuraga333, mgorny, sam |
| Priority: | Normal | Keywords: | PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://wiki.gentoo.org/wiki/Project:Python/python-exec | ||
| See Also: |
https://github.com/gentoo/gentoo/pull/19089 https://bugs.gentoo.org/show_bug.cgi?id=702806 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Stéphane Veyret
2021-01-16 08:14:48 UTC
It doesn't matter which interpreter you "eselect python" as default as it's just an order of preference. Installed packages will pick an interpreter that works for them based on build-time TARGETS, either through python-exec or having a version-specific shebang. python2_7 will be cleaned from that eventually, but with no packages using the target it's not any more harmful than a random string. Well, that’s not fully true. Let me give you an example: I have a custom Python script running on my server, and this script can use any python interpreter. Before I eselect-ed the 3.8 version, the script was running using Python 3.9. But this script requires some dependencies, which were searched in the 3.9 folder, but not found, because only compiled for 3.8. It took me a while to notice that the script was not running anymore and to find why. Ionen is perfectly right: PYTHON_TARGET* takes care of consistency and dependecy resolution from the package manager view. The default interpreter to use for your scripts is under your responsibility, and it is done using eselect python. It probably makes sense to choose the version which installed system python packages, that are necessary for your scripts, are available in. If you wrote an ebuild for your scripts making use of the python* eclasses, you could enforce that using the package manager as well. OK, maybe I was not clear. My script can run with any Python3 interpreter. The problem is that when installed, Python 3.9 becomes the default interpreter, so my script uses it. But because PYTHON_TARGET does not specify python3_9, my script’s dependencies are not installed in the 3.9 folder, making my script failing. I can understand that, when one wants a specific installation, he may break his environment. But here, it is not the case. Do you feel comfortable with the fact that an « out of the box » installation can break? Moreover, what is the interest of having PYTHON_TARGET inconsistent with the stable Python packages? (In reply to Stéphane Veyret from comment #4) > OK, maybe I was not clear. My script can run with any Python3 interpreter. > The problem is that when installed, Python 3.9 becomes the default > interpreter, so my script uses it. I can't confirm that. $ eselect python list > Available Python interpreters, in order of preference: > [1] python3.8 > [2] python3.9 (fallback) > [3] python2.7 (fallback) # emerge -k1qa dev-lang/python:3.9 > [binary NS ] dev-lang/python-3.9.0-r1 [2.7.18-r5, 3.8.6-r1] > >>> Running pre-merge checks for dev-lang/python-3.9.0-r1 > >>> Emerging binary (1 of 1) dev-lang/python-3.9.0-r1::gentoo > >>> Installing (1 of 1) dev-lang/python-3.9.0-r1::gentoo $ eselect python list > Available Python interpreters, in order of preference: > [1] python3.8 > [2] python3.6 (uninstalled) > [3] python3.9 (fallback) > [4] python2.7 (fallback) The default remains unchanged after new slot of python is installed. The new version is added to available interpreters, is all that happens. It is simply your responsibility when you make the switch; it likely correlates with 'the' default PYTHON_TARGET, but you may have two or three enabled at the same time. And how should Portage make that decision for you? I’d just write an ebuild for the script or use a virtualenv. (In reply to Andreas Sturmlechner from comment #5) > The default remains unchanged after new slot of python is installed. The new > version is added to available interpreters, is all that happens. It is > simply your responsibility when you make the switch; it likely correlates > with 'the' default PYTHON_TARGET, but you may have two or three enabled at > the same time. And how should Portage make that decision for you? Maybe you eselect-ed the python version some time ago, and this choice was kept when installing a new version. I did not, never. I always let the system choose what it wants. And it lately decided to choose Python 3.9 while dependencies where not compiled accordingly. (In reply to Sam James from comment #6) > I’d just write an ebuild for the script or use a virtualenv. I know there are workarounds. I personally simply selected the version of Python I wanted to use. I just think that the default behavior is an issue and that PYTHON_TARGET should be consistent with stable Python slots. No-one gave me an answer to the interest of being inconsistent, still… I faced the same problem just now on another computer: I was trying to build a system using Yocto, and Yocto is using Python. There again, my compilation failed because of a missing package, which was actually due to the fact that on this computer also, Python 3.9 was the default version, but the package, installed, was not compiled for the version. Don’t you think it is somehow annoying? I think the root issue is that Python 3.9 is installed unnecessarily. Could you try 'emerge --depclean -v' and see if Portage considers it required for some reason? (In reply to Michał Górny from comment #9) > I think the root issue is that Python 3.9 is installed unnecessarily. Could > you try 'emerge --depclean -v' and see if Portage considers it required for > some reason? Sure! For example, on one of my computers: dev-lang/python-3.9.0 pulled in by: app-crypt/mit-krb5-1.18.2-r2 requires dev-lang/python:3.9 app-misc/ca-certificates-20200601.3.53 requires dev-lang/python:3.9 app-text/iso-codes-4.4 requires dev-lang/python:3.9 dev-lang/rust-1.47.0-r2 requires dev-lang/python:3.9 dev-lang/spidermonkey-78.6.0 requires dev-lang/python:3.9 dev-libs/jsoncpp-1.9.4 requires dev-lang/python:3.9 dev-libs/libevdev-1.10.0 requires dev-lang/python:3.9 dev-libs/serd-0.30.6 requires dev-lang/python:3.9[threads(+)] dev-libs/zziplib-0.13.71_p20201021 requires dev-lang/python:3.9 dev-util/ninja-1.10.1 requires dev-lang/python:3.9 dev-util/yocto-dep-meta-3.2.1 requires dev-lang/python gnome-base/gnome-settings-daemon-3.36.1 requires dev-lang/python:3.9 mail-client/thunderbird-78.6.0 requires dev-lang/python:3.9[ncurses,sqlite,ssl] media-libs/libepoxy-1.5.4 requires dev-lang/python:3.9[xml(+)] media-libs/libglvnd-1.3.2-r2 requires dev-lang/python:3.9 media-libs/libmypaint-1.6.1 requires dev-lang/python:3.9 media-libs/mesa-20.2.4 requires dev-lang/python:3.9 media-libs/sratom-0.6.6 requires dev-lang/python:3.9[threads(+)] media-libs/suil-0.10.8 requires dev-lang/python:3.9[threads(+)] net-libs/libpsl-0.21.0 requires dev-lang/python:3.9 net-libs/nodejs-14.15.1 requires dev-lang/python:3.9[threads(+)] net-wireless/crda-4.14 requires dev-lang/python:3.9 sci-astronomy/stellarium-0.20.3 requires dev-lang/python:3.9 sys-devel/llvm-11.0.0 requires dev-lang/python:3.9 sys-libs/compiler-rt-11.0.0 requires dev-lang/python:3.9 sys-libs/compiler-rt-sanitizers-11.0.0 requires dev-lang/python:3.9 sys-libs/glibc-2.32-r3 requires dev-lang/python:3.9 x11-libs/libxcb-1.14 requires dev-lang/python:3.9[xml] Right, with || deps that isn't exactly helpful. (In reply to Michał Górny from comment #9) > I think the root issue is that Python 3.9 is installed unnecessarily. Could > you try 'emerge --depclean -v' and see if Portage considers it required for > some reason? Sounds like a duplicate of bug 702806 (and its several duplicates). (In reply to Sam James from comment #12) > Sounds like a duplicate of bug 702806 (and its several duplicates). Exact Sam, Thank you! I’ll close the issue as duplicate. *** This bug has been marked as a duplicate of bug 702806 *** Let's consider solving this independently of Portage behavior. I guess automatically enabling the newest version when it's not in PYTHON_TARGETS is against the rule of least surprise. The simplest option I can think of would be to split python-exec.conf into a separate package and edit the installed default based on PYTHON_TARGETS. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9939442407c5a141eb70af5fd98ebed7bb6af691 commit 9939442407c5a141eb70af5fd98ebed7bb6af691 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2021-01-17 11:16:48 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2021-01-19 13:34:08 +0000 dev-lang/python-exec-conf: New package for python-exec.conf Split python-exec.conf file to a separate package, so that we can use PYTHON_TARGETS to control its default contents. This can be used to ensure that newer Python implementations are not used by default unless the user actually enables the relevant target. Note that we can't reuse PYTHON_TARGETS in dev-lang/python-exec this way. They are used to ensure that dev-lang/python-exec is rebuilt with the correct implementation list. Closes: https://bugs.gentoo.org/765598 Signed-off-by: Michał Górny <mgorny@gentoo.org> dev-lang/python-exec-conf/Manifest | 1 + dev-lang/python-exec-conf/metadata.xml | 8 +++++ .../python-exec-conf/python-exec-conf-2.4.6.ebuild | 40 ++++++++++++++++++++++ 3 files changed, 49 insertions(+) |
