9:27 a.m.
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
11:41 a.m.
New subject: Renaming pythonXY packages to pythonX.Y (e.g. python39 to
python3.9)
Le mercredi 29 avril 2020 à 16:27 +0200, Tomas Orsava a écrit :
Hi,
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).
If you go into cleanup & renaming mode, please add a '-' between python
and the version, so it is consistent with the way versionned names have
been done in the distribution for a long time.
For example, I see we have a
java-1.8.0-openjdk
java-11-openjdk
java-latest-openjdk
As you see the magic '-' makes it possible to use non-numeric version
qualifiers later without breaking naming conventions.
Regards
--
Nicolas Mailhot
12:18 p.m.
New subject: Renaming pythonXY packages to pythonX.Y (e.g. python39 to
python3.9)
On 29. 04. 20 18:41, Nicolas Mailhot via devel wrote:
Le mercredi 29 avril 2020 à 16:27 +0200, Tomas Orsava a écrit :
Hi,
> 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).
If you go into cleanup & renaming mode, please add a '-' between python
and the version, so it is consistent with the way versionned names have
been done in the distribution for a long time.
For example, I see we have a
java-1.8.0-openjdk
java-11-openjdk
java-latest-openjdk
As you see the magic '-' makes it possible to use non-numeric version
qualifiers later without breaking naming conventions.
No, sorry.
Reason 1:
The command is named pythonX.Y, not python-X.Y and we want this consistent.
Reason 2:
The packaging guidelines say:
"""
All [compat packages] MUST include the base name suffixed by either:
* The package version, which SHOULD include the periods present in the original
version. [...] If the base package name does not end with a digit, the version
MUST be *directly appended* to the package name with *no intervening separator*.
* a hyphen ("-") followed by a descriptive suffix such as "stable"
which
provides some indication as to the nature of the packaged version.
"""
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:37 p.m.
New subject: Renaming pythonXY packages to pythonX.Y (e.g. python39 to
python3.9)
Le mercredi 29 avril 2020 à 19:18 +0200, Miro Hrončok a écrit :
All [compat packages] MUST include the base name suffixed by either:
Well we are not creating a compat package here and not adding an hyphen
creates an artificial numeric/non numeric special case.
But, I see someone formalised the special case in compat guidelines,
ignoring distribution history that showed versionned naming could
easily be done without special cases that annoys humans and break
automation and scripts for years afterwards, therefore, do as you want.
--
Nicolas Mailhot
12:43 p.m.
New subject: Renaming pythonXY packages to pythonX.Y (e.g. python39 to
python3.9)
On 29. 04. 20 19:37, Nicolas Mailhot wrote:
Le mercredi 29 avril 2020 à 19:18 +0200, Miro Hrončok a écrit :
> All [compat packages] MUST include the base name suffixed by either:
Well we are not creating a compat package here and not adding an hyphen
creates an artificial numeric/non numeric special case.
But, I see someone formalised the special case in compat guidelines,
ignoring distribution history that showed versionned naming could
easily be done without special cases that annoys humans and break
automation and scripts for years afterwards, therefore, do as you want.
I don't agree that "python3.9" as a package name annoys humans or break
automation scripts. How does it?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:50 p.m.
New subject: Renaming pythonXY packages to pythonX.Y (e.g. python39 to
python3.9)
Le mercredi 29 avril 2020 à 19:43 +0200, Miro Hrončok a écrit :
On 29. 04. 20 19:37, Nicolas Mailhot wrote:
> Le mercredi 29 avril 2020 à 19:18 +0200, Miro Hrončok a écrit :
>
> > All [compat packages] MUST include the base name suffixed by
> > either:
> Well we are not creating a compat package here and not adding an
> hyphen
> creates an artificial numeric/non numeric special case.
>
> But, I see someone formalised the special case in compat
> guidelines,
> ignoring distribution history that showed versionned naming could
> easily be done without special cases that annoys humans and break
> automation and scripts for years afterwards, therefore, do as you
> want.
I don't agree that "python3.9" as a package name annoys humans or
break automation scripts. How does it?
As soon as you have a different naming convention for numeric and non
numeric qualifiers all the code that manipulates your package names
must test if the qualifier is numeric or not, to add the hyphen or not.
It is much simpler to just assume -<qualifier> everywhere, without
testing <qualifier> in any way.
That’s why
%package XXX
will create foo-XXX by default, and not ask you to split hairs and test
if XXX is numeric or not (yes the hyphen separator is built in rpm core
logic)
--
Nicolas Mailhot
12:57 p.m.
New subject: Renaming pythonXY packages to pythonX.Y (e.g. python39 to
python3.9)
On 29. 04. 20 19:50, Nicolas Mailhot wrote:
> I don't agree that "python3.9" as a package name
annoys humans or
> break automation scripts. How does it?
As soon as you have a different naming convention for numeric and non
numeric qualifiers all the code that manipulates your package names
must test if the qualifier is numeric or not, to add the hyphen or not.
It is much simpler to just assume -<qualifier> everywhere, without
testing <qualifier> in any way.
That’s why
%package XXX
will create foo-XXX by default, and not ask you to split hairs and test
if XXX is numeric or not (yes the hyphen separator is built in rpm core
logic)
What you say is true. I still don't agree that "python3.9" as a package name
annoys humans. And I don't understand what kind of automation are we talking
about that needs to parse the "3.9" part and figure out it is a
"qualifier".
Such automation is broken anyway, because it cannot tell if python-requests is a
Python library or a Python "qualifier".
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1:09 p.m.
New subject: Renaming pythonXY packages to pythonX.Y (e.g. python39 to
python3.9)
Le mercredi 29 avril 2020 à 19:57 +0200, Miro Hrončok a écrit :
Such automation is broken anyway, because it cannot tell if python-
requests is a
Python library or a Python "qualifier".
It is no more broken than automation that "knows" test<numeric> means
<numeric> is a version. Of course before you apply such automation you
start by filtering package names in some way. What you do *not* want to
do is use two different processing patterns instead of one.
--
Nicolas Mailhot
1:28 p.m.
New subject: Renaming pythonXY packages to pythonX.Y (e.g. python39 to
python3.9)
Le mercredi 29 avril 2020 à 19:57 +0200, Miro Hrončok a écrit :
And I don't understand what kind of automation are we
talking about that needs to parse the "3.9" part and figure out it is
a "qualifier".
It mostly hits you in the package creation code. The Go macro code will
just dump -qualifier- in the name without bothering with arcane testing
for example.
--
Nicolas Mailhot
2:32 a.m.
New subject: Renaming pythonXY packages to pythonX.Y (e.g. python39 to
python3.9)
On Wed, Apr 29, 2020 at 07:57:13PM +0200, Miro Hrončok wrote:
On 29. 04. 20 19:50, Nicolas Mailhot wrote:
>>I don't agree that "python3.9" as a package name annoys humans or
>>break automation scripts. How does it?
>As soon as you have a different naming convention for numeric and non
>numeric qualifiers all the code that manipulates your package names
>must test if the qualifier is numeric or not, to add the hyphen or not.
>
>It is much simpler to just assume -<qualifier> everywhere, without
>testing <qualifier> in any way.
>
>That’s why
>
>%package XXX
>
>will create foo-XXX by default, and not ask you to split hairs and test
>if XXX is numeric or not (yes the hyphen separator is built in rpm core
>logic)
What you say is true. I still don't agree that "python3.9" as a
package name annoys humans. And I don't understand what kind of
automation are we talking about that needs to parse the "3.9" part
and figure out it is a "qualifier".
Such automation is broken anyway, because it cannot tell if
python-requests is a Python library or a Python "qualifier".
Yep, having a dash there would create potential conflicts with python
modules names. And it would be confusing for users, who wouldn't know
if python-latest is a the module 'latest' or not.
+1 to the renaming as proposed.
Zbyszek
11:51 a.m.
On Wed, Apr 29, 2020 at 10:28 AM Tomas Orsava <torsava(a)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.
--
真実はいつも一つ！/ Always, there's only one truth!
12:28 p.m.
New subject: Renaming pythonXY packages to pythonX.Y (e.g. python39 to
python3.9)
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:28 p.m.
On Wed, Apr 29, 2020 at 4:28 PM Tomas Orsava <torsava(a)redhat.com> wrote:
Hello everyone.
I’m working on a change to rename pythonXY packages to pythonX.Y, e.g.
python39 to python3.9.
Changing it to pythonX.Y makes sense I think. It's likely going to be a lot
of work for little gain, but I appreciate that you are taking it on!
Cleanups like this make the packaging much nicer to use in the future.
+1 from me.
--
Kalev
7:07 p.m.
New subject: Renaming pythonXY packages to pythonX.Y (e.g. python39 to
python3.9)
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1446
days inactive
1455
days old
13 comments
6 participants
participants (6)
-
Kalev Lember -
Miro Hrončok -
Neal Gompa -
Nicolas Mailhot -
Tomas Orsava -
Zbigniew Jędrzejewski-Szmek