I'm currently working on the update for python-Levenshtein [1] and I have a question about the best way to proceed.
In the intervening time since the last release we have packaged, a new maintainer has taken over maintenance, and built the updates around a stack of other packages (rapidfuzz-cpp, python-rapidfuzz, scikit-build, etc). Now that all these dependencies are available I can look to actually do the update. As part of the updates, the current maintainer has deprecated the original pypi name of "python-Levenshtein" in favor of the more typical name without the "python-" prefix. He is continuing to maintain the "python-Levenshtein" pypi package for compatibility, but now it is just an empty package which defines "Levenshtein" as a dependency [2]. This means the upstream for the Fedora python-Levenshtein package must point to the new Levenshtein package in order to get the actual package contents. However, this means the metadata for the package indicates the name "Levenshtein" which translate to a provide for "python3.11dist(levenshtein)", but that is different than the currently provided "python3.11dist(python-levenshtein)", which current dependencies require. One option would be to simply manually add a "python3.11dist(python-levenshtein)" provide, but it seems this seems specifically prohibited in the Python packaging guidelines [3].
I think there are 2 options: - Manually provide the legacy name outside of the python package meta-data - Rebuild all users of the provide to use the new name
The main downside to the second approach is that nothing would provide the python-Levenshtein name, which is still present and usable via pypi and perfectly compatible with the current library implementation.
So what is the appropriate course of action here?
Thanks for the help, Troy
1: https://bugzilla.redhat.com/show_bug.cgi?id=1036607 2: https://github.com/maxbachmann/python-Levenshtein/blob/main/setup.cfg 3: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#Machine-re...
Hi Troy.
On 29. 05. 23 18:01, Troy Curtis Jr wrote:
I'm currently working on the update for python-Levenshtein [1] and I have a question about the best way to proceed.
In the intervening time since the last release we have packaged, a new maintainer has taken over maintenance, and built the updates around a stack of other packages (rapidfuzz-cpp, python-rapidfuzz, scikit-build, etc). Now that all these dependencies are available I can look to actually do the update. As part of the updates, the current maintainer has deprecated the original pypi name of "python-Levenshtein" in favor of the more typical name without the "python-" prefix. He is continuing to maintain the "python-Levenshtein" pypi package for compatibility, but now it is just an empty package which defines "Levenshtein" as a dependency [2]. This means the upstream for the Fedora python-Levenshtein package must point to the new Levenshtein package in order to get the actual package contents. However, this means the metadata for the package indicates the name "Levenshtein" which translate to a provide for "python3.11dist(levenshtein)", but that is different than the currently provided "python3.11dist(python-levenshtein)", which current dependencies require. One option would be to simply manually add a "python3.11dist(python-levenshtein)" provide, but it seems this seems specifically prohibited in the Python packaging guidelines [3].
And there is a reason. If the package "claimed" to be python3dist(python-levenshtein), yet the Python metadata would say it's levenshtein, all automation that generates requirements for python3dist(python-levenshtein) would happily accept it, but fail on Python level. For example, the %pyproject_buildrequires macro, when it encounters an unmet dependency on levenshtein on the Python level, prints out python3dist(levenshtein) and restarts for dnf to take over. dnf then installs the package but the macro still does not see the package on Python level, so it prints it out again and restarts...
I think there are 2 options:
- Manually provide the legacy name outside of the python package meta-data
Please don't.
- Rebuild all users of the provide to use the new name
It's not that many:
$ repoquery -q --repo=rawhide{,-source} --whatrequires 'python3.11dist(python-levenshtein)' --whatrequires 'python3dist(python-levenshtein)' paperwork-0:2.1.2-2.fc38.src python-paperwork-backend-0:2.1.2-2.fc38.src python3-paperwork-0:2.1.2-2.fc38.noarch python3-paperwork-backend-0:2.1.2-2.fc38.noarch
The main downside to the second approach is that nothing would provide the python-Levenshtein name, which is still present and usable via pypi and perfectly compatible with the current library implementation.
But do we need it in Fedora?
If you really need this, you could insert a second dist-info metadata to the package, so it would ship:
%{python_sitearch}/...actual content here... %{python_sitearch}/Levenshtein-0.21.0.dist-info/ %{python_sitelib}/python_Levenshtein-0.21.0.dist-info/
That way, it provides both names on Python and RPM level both.
But I consider that an overkill.
So what is the appropriate course of action here?
Please, attempt to change the dependents.
On Tue, May 30, 2023, 3:13 AM Miro Hrončok mhroncok@redhat.com wrote:
Hi Troy.
On 29. 05. 23 18:01, Troy Curtis Jr wrote:
I'm currently working on the update for python-Levenshtein [1] and I
have a
question about the best way to proceed.
In the intervening time since the last release we have packaged, a new maintainer has taken over maintenance, and built the updates around a
stack of
other packages (rapidfuzz-cpp, python-rapidfuzz, scikit-build, etc). Now
that
all these dependencies are available I can look to actually do the
update. As
part of the updates, the current maintainer has deprecated the original
pypi
name of "python-Levenshtein" in favor of the more typical name without
the
"python-" prefix. He is continuing to maintain the "python-Levenshtein"
pypi
package for compatibility, but now it is just an empty package which
defines
"Levenshtein" as a dependency [2]. This means the upstream for the
Fedora
python-Levenshtein package must point to the new Levenshtein package in
order
to get the actual package contents. However, this means the metadata for
the
package indicates the name "Levenshtein" which translate to a provide
for
"python3.11dist(levenshtein)", but that is different than the currently provided "python3.11dist(python-levenshtein)", which current
dependencies
require. One option would be to simply manually add a "python3.11dist(python-levenshtein)" provide, but it seems this seems specifically prohibited in the Python packaging guidelines [3].
And there is a reason. If the package "claimed" to be python3dist(python-levenshtein), yet the Python metadata would say it's levenshtein, all automation that generates requirements for python3dist(python-levenshtein) would happily accept it, but fail on Python level. For example, the %pyproject_buildrequires macro, when it encounters an unmet dependency on levenshtein on the Python level, prints out python3dist(levenshtein) and restarts for dnf to take over. dnf then installs the package but the macro still does not see the package on Python level, so it prints it out again and restarts...
I think there are 2 options:
- Manually provide the legacy name outside of the python package
meta-data
Please don't.
- Rebuild all users of the provide to use the new name
It's not that many:
$ repoquery -q --repo=rawhide{,-source} --whatrequires 'python3.11dist(python-levenshtein)' --whatrequires 'python3dist(python-levenshtein)' paperwork-0:2.1.2-2.fc38.src python-paperwork-backend-0:2.1.2-2.fc38.src python3-paperwork-0:2.1.2-2.fc38.noarch python3-paperwork-backend-0:2.1.2-2.fc38.noarch
The main downside to the second approach is that nothing would provide
the
python-Levenshtein name, which is still present and usable via pypi and perfectly compatible with the current library implementation.
But do we need it in Fedora?
If you really need this, you could insert a second dist-info metadata to the package, so it would ship:
%{python_sitearch}/...actual content here... %{python_sitearch}/Levenshtein-0.21.0.dist-info/ %{python_sitelib}/python_Levenshtein-0.21.0.dist-info/
That way, it provides both names on Python and RPM level both.
But I consider that an overkill.
I presume that the name change would be considered a breaking change, since any applications using the system libraries expecting that name would not install properly (outside of Fedora packages which could be updated together with the change). This in spite of the fact that the actual API is fully compatible. That is the one case that seems like it might be worth while to add this second distinfo.
So what is the appropriate course of action here?
Please, attempt to change the dependents.
Since the requires generally come from the package metadata itself, does this mean changing upstream for each dependency? Or just patch for our Fedora packages? Presumably they could be patched and then built together with the updated name, I presume this is where side tags come in to play? (It'll be a new experience for me!)
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
On 30. 05. 23 15:13, Troy Curtis Jr wrote:
Please, attempt to change the dependents.Since the requires generally come from the package metadata itself, does this mean changing upstream for each dependency? Or just patch for our Fedora packages? Presumably they could be patched and then built together with the updated name, I presume this is where side tags come in to play? (It'll be a new experience for me!)
I'd send a PR upstream and use that as a patch for Fedora. Using side tags to ship this is a good idea, yes.
python-devel@lists.fedoraproject.org
-
Miro Hrončok -
Troy Curtis Jr