Re: [gentoo-dev] [News item review v4] Python preference to follow PYTHON_TARGETS
210125 Michał Górny wrote:
> Changed eselect-python dep removal date to July 2021.
> Not sure if there's a reason to display it to stable users today,
> or delay until the stable request is actually filed.
I've been using Gentoo since 2003 , happily enough most of the time ;
I'm an ordinary desktop user without any special requirements.
Python versions have been one of the reasons for the exceptions.
I finally managed to remove 2.7 from my system yesterday.
I do appreciate your work in this area,
but I can make no sense of the news item below.
> Title: Python preference to follow PYTHON_TARGETS
> Author: Michał Górny
> Posted: 2021-01-24
> Revision: 1
> News-Item-Format: 2.0
>
> On 2021-02-01 stable users will switch to a new method of updating
> the preferred Python versions that employs the configuration update
> mechanism in order to follow PYTHON_TARGETS.
What are "preferred Python versions" ? Why are they multiple, not one ?
What is the "configuration update mechanism",
how does it "follow PYTHON_TARGETS" & why are they both needed ?
> We will also deprecate app-eselect/eselect-python,
> and it will stop being installed by default after 2021-07-01.
Why has there been this 3rd method of managing Python versions ?
Why might it still be needed by users ?
> If you wish to use the newest Python version present
> in your PYTHON_TARGETS, you only have to accept configuration changes.
Why doesn't Python behave like most other packages,
ie use the latest installed version ? Why does PYTHON_TARGETS exist ?
Why are the "targets" ? -- it sounds as if they may not be achieved.
What are the "configuration changes" ?
Do you mean those in /etc/python-exec ?
> If you wish to customize the behavior, read on.
I have no wish to customise Python. I don't use it to develop programs ;
it is installed only as a requirement for other packages, eg Portage.
I do use it for a small script to work as a CLI calculator.
Given this, I won't comment on the rest of the news item,
but it makes even less sense to me than the section above.
In /etc/portage/make.conf , I have
USE_PYTHON="2.7 3.5 3.6"
PYTHON_TARGETS="python3_7"
PYTHON_SINGLE_TARGET="python3_7"
'eselect python list' gives
Available Python interpreters, in order of preference:
[1] python3.7
[2] python3.6 (uninstalled)
/etc/python-exec/ contains 1 file 'python-exec.conf',
which says (besides many lines of comment) :
python3.7
python3.6
'eix python' shows
[I] dev-lang/python
Available versions:
(2.7) 2.7.18-r5 ~2.7.18-r6
(3.6) 3.6.12-r1(3.6/3.6m)^t ~3.6.12-r2(3.6/3.6m)^t
(3.7) 3.7.9-r1(3.7/3.7m)^t ~3.7.9-r2(3.7/3.7m)^t
(3.8) 3.8.6-r1^t ~3.8.7-r1^t
(3.9) 3.9.0-r1^t ~3.9.1-r1^t
(3.10) ~3.10.0_alpha3-r1^t ~3.10.0_alpha4^t
{-berkdb bluetooth build examples gdbm hardened ipv6 libressl +ncurses
+readline sqlite +ssl test +threads tk verify-sig +wide-unicode wininst +xml
ELIBC="uclibc"}
Installed versions: 3.7.9-r1(3.7/3.7m)^t([2021-01-24 23:26:15])(gdbm ncurses
readline sqlite ssl tk xml -bluetooth -build -examples -hardened -ipv6
-libressl -test -wininst) 3.8.6-r1(3.8)^t([2021-01-24 23:28:48])(gdbm ncurses
readline sqlite ssl tk xml -bluetooth -build -examples -hardened -ipv6
-libressl -test -wininst) 3.9.0-r1(3.9)^t([2021-01-24 23:31:53])(gdbm ncurses
readline sqlite ssl tk xml -bluetooth -build -examples -hardened -ipv6
-libressl -test -wininst)
I can't understand why there are so many ways to control Python
nor which one users are supposed to use nor how to reconcile them.
I would be very happy simply to use 3.9 for all Python purposes.
Thanks again for your hard work on this + other areas of Gentoo.
--
,,
SUPPORT ___//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT`-O--O---' purslowatcadotinterdotnet
Re: [gentoo-dev] Not-Forking 0.3.1 with ebuild
A bit off topic to whether or not there's an ebuild/maintainer for it, but their homepage example is cringe-y. Instead of using the built-in features of Git like submodules and rebasing, depend on an external tool to make your repository even more messy?
Re: [gentoo-dev] [News item review v4] Python preference to follow PYTHON_TARGETS
Hi, Changed eselect-python dep removal date to July 2021. Not sure if there's a reason to display it to stable users today, or delay until the stable request is actually filed. ``` Title: Python preference to follow PYTHON_TARGETS Author: Michał Górny Posted: 2021-01-24 Revision: 1 News-Item-Format: 2.0 On 2021-02-01 stable users will switch to a new method of updating the preferred Python versions that employs the configuration update mechanism in order to follow PYTHON_TARGETS. We will also deprecate app-eselect/eselect-python, and it will stop being installed by default after 2021-07-01. If you wish to use the newest Python version present in your PYTHON_TARGETS, you only have to accept configuration changes. If you wish to customize the behavior, read on. Since 2017, /usr/bin/python and the related non-versioned symlinks are wrapped through dev-lang/python-exec. The list of preferred Python implementations is stored in /etc/python-exec/python-exec.conf and/or per-program /etc/python-exec/.conf configuration files. To preserve backwards compatibility, app-eselect/eselect-python remained a wrapper that updated this file. However, this mechanism alone has proven inconvenient to end users who had to update python-exec.conf whenever the default PYTHON_TARGETS changed. Thanks to the fallback logic, this was not a major problem for software installed via Gentoo packages that always ensure that a supported implementation is used. However, users have reported that whenever the preference for /usr/bin/python mismatched their PYTHON_TARGETS, their custom scripts would break due to unsatisfied dependencies. This does not follow the principle of least surprise. For this reason, we have decided to change the default python-exec configuration to match PYTHON_TARGETS by default, in the eclass preference order, that is from the newest CPython version to oldest, with alternative Python implementations coming afterwards. This change will be propagated via the configuration protection mechanism whenever dev-lang/python-exec-conf is installed or rebuilt due to PYTHON_TARGETS changes. This will permit the users to interactively confirm the updates. If the new default is not correct for you, please use your preferred configuration update tool to discard or edit the new configuration file. Furthermore, dev-lang/python will no longer attempt to automatically update the Python interpreter preference, or pull in eselect-python automatically. If you wish to continue using it, please install/record it explicitly to ensure that it is not unmerged, e.g.: emerge -n app-eselect/eselect-python ``` -- Best regards, Michał Górny
[gentoo-dev] Last-rites: net-analyzer/jffnms
# Brian Evans (2021-01-25) # Dead upstream. Relies on soon to be removed wddx support in PHP. # wddx in general failed overall as a protocol. No real maintainer. # Removal in 30 days. Bug #688066 net-analyzer/jffnms OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Not-Forking 0.3.1 with ebuild
Not-Forking addresses the upstream vendoring/forking issue, as per the diagrams and explanation at https://lumosql.org/src/not-forking : > Not-forking avoids duplicating the source code of one project within another > project, where the projects > are external to each other. This is something that is not handled by version > control systems such > as Fossil, Git, or GitHub. > > Not-forking avoids project-level forking by largely automating change > management in ways that a version control system cannot. Not-Forking has an ebuild, but not a maintainer. I figured this is the place to mention it. Best -- Dan Shearer d...@shearer.org
