On Tue, May 30, 2023, 3:13 AM Miro Hrončok <mhron...@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
>
>
_______________________________________________
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
