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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
