Hello everyone. I’m working on a change to rename pythonXY packages to pythonX.Y, e.g. python39 to python3.9.
*Motivation:* When you install an additional Python interpreter, the command that runs it contains a dot (e.g. /usr/bin/python3.9) but the package name does not (e.g. dnf install python39). The name without a dot is a technical debt that we carry since (at least) the python26 package in RHEL 5 for consistency. The name with the dot makes much more sense to Red Hat Python maintainers. It’s a minor inconsistency, but we'd like to get it right in RHEL, and since RHEL splits off from Fedora, it will be bugging us still in 2030+ unless we fix it now. Especially with the likely coming version 3.10 the package name python310 is confusing. This will also get us in sync with e.g. Debian package names.
*Backwards compatibility:* We plan to create new components in rawhide containing the dot (e.g. python3.9) for all Python interpreters (except soon-to-be-retired python34 and python26) and push the git commits from pythnoXY to them to preserve the history. The packages will Provide and Obsolete the old name without a dot (e.g. python39). The current packages already provide the name with the dot, so this will be just a switch between real name and virtual provide. Therefore any package that depends on these components will continue to work just fine. And in time we’d like to fix all of those to use the new name, which is backwards compatible, because it is already provided now (as a side note, the packages are generally just recommended, not required).
*Technical details:* There has been a recent rawhide-only change to the %python_provide macro that acts on packages named `python3-foo` and adds for them a new Provide `python38-foo`. We’d like to change this to Provide `python3.8-foo` instead. Since this has been rawhide-only so far, and because there’s no real reason to depend on these provides yet, we don’t expect any breakage.
What do you think? Do you foresee any problems? All the best, Tomas
On Wed, Apr 29, 2020 at 10:28 AM Tomas Orsava torsava@redhat.com wrote:
Hello everyone. I’m working on a change to rename pythonXY packages to pythonX.Y, e.g. python39 to python3.9.
Motivation: When you install an additional Python interpreter, the command that runs it contains a dot (e.g. /usr/bin/python3.9) but the package name does not (e.g. dnf install python39). The name without a dot is a technical debt that we carry since (at least) the python26 package in RHEL 5 for consistency. The name with the dot makes much more sense to Red Hat Python maintainers. It’s a minor inconsistency, but we'd like to get it right in RHEL, and since RHEL splits off from Fedora, it will be bugging us still in 2030+ unless we fix it now. Especially with the likely coming version 3.10 the package name python310 is confusing. This will also get us in sync with e.g. Debian package names.
Backwards compatibility: We plan to create new components in rawhide containing the dot (e.g. python3.9) for all Python interpreters (except soon-to-be-retired python34 and python26) and push the git commits from pythnoXY to them to preserve the history. The packages will Provide and Obsolete the old name without a dot (e.g. python39). The current packages already provide the name with the dot, so this will be just a switch between real name and virtual provide. Therefore any package that depends on these components will continue to work just fine. And in time we’d like to fix all of those to use the new name, which is backwards compatible, because it is already provided now (as a side note, the packages are generally just recommended, not required).
Technical details: There has been a recent rawhide-only change to the %python_provide macro that acts on packages named `python3-foo` and adds for them a new Provide `python38-foo`. We’d like to change this to Provide `python3.8-foo` instead. Since this has been rawhide-only so far, and because there’s no real reason to depend on these provides yet, we don’t expect any breakage.
What do you think? Do you foresee any problems?
I'm good with this plan, except for one thing I thought of we need to address: How do we do comparisons for python versions? Will we still have a %python_version_nodots macro so that we can do integer comparisons? I know that people have been abusing the %python3_pkgversion macro for doing this (which you shouldn't be doing!), so we need an official guideline for how to do those comparisons.
On 29. 04. 20 18:51, Neal Gompa wrote:
What do you think? Do you foresee any problems?
I'm good with this plan, except for one thing I thought of we need to address: How do we do comparisons for python versions?
In spec %ifs? I've been doing it with %python3_version_nodots. That'll work until there is 3.10 and later 4.0. At that point, it will break because 310 > 40. If there is Python 4, this will be the smallest of our problems.
Will we still have a %python_version_nodots macro so that we can do integer comparisons?
Yes. The macro has the Python version without dots. It has nothing to do with package names and never had.
I know that people have been abusing the %python3_pkgversion macro for doing this (which you shouldn't be doing!)
Oh my gods. That cannot even work, %python3_pkgversion is always 3 in Fedora. Are you talking EPEL? EPEL Python packaging is a spaghetti western, if people do this, they are on their own.
I've recently seen this in Fedora spec:
pytest-%{python3_pkgversion}
Well, it works. In the same way this works:
%if %{fedora} > %{python3_pkgversion}0
Don't do this. Ever.
so we need an official guideline for how to do those comparisons.
Good point. I'll take a note.
On 29. 04. 20 16:27, Tomas Orsava wrote:
Hello everyone. I’m working on a change to rename pythonXY packages to pythonX.Y, e.g. python39 to python3.9.
*Motivation:* When you install an additional Python interpreter, the command that runs it contains a dot (e.g. /usr/bin/python3.9) but the package name does not (e.g. dnf install python39). The name without a dot is a technical debt that we carry since (at least) the python26 package in RHEL 5 for consistency. The name with the dot makes much more sense to Red Hat Python maintainers. It’s a minor inconsistency, but we'd like to get it right in RHEL, and since RHEL splits off from Fedora, it will be bugging us still in 2030+ unless we fix it now. Especially with the likely coming version 3.10 the package name python310 is confusing. This will also get us in sync with e.g. Debian package names.
*Backwards compatibility:* We plan to create new components in rawhide containing the dot (e.g. python3.9) for all Python interpreters (except soon-to-be-retired python34 and python26) and push the git commits from pythnoXY to them to preserve the history. The packages will Provide and Obsolete the old name without a dot (e.g. python39). The current packages already provide the name with the dot, so this will be just a switch between real name and virtual provide. Therefore any package that depends on these components will continue to work just fine. And in time we’d like to fix all of those to use the new name, which is backwards compatible, because it is already provided now (as a side note, the packages are generally just recommended, not required).
*Technical details:* There has been a recent rawhide-only change to the %python_provide macro that acts on packages named `python3-foo` and adds for them a new Provide `python38-foo`. We’d like to change this to Provide `python3.8-foo` instead. Since this has been rawhide-only so far, and because there’s no real reason to depend on these provides yet, we don’t expect any breakage.
The renaming has been done. Please report any problems.
python-devel@lists.fedoraproject.org
-
Miro Hrončok -
Neal Gompa -
Tomas Orsava