Re: Guidance for a python package update
On Tue, May 30, 2023, 3:13 AM Miro Hrončok 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
Guidance for a python package update
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-readable-provides ___ 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
Re: Parselmouth Badge
On Mon, Nov 6, 2017, 5:02 AM Petr Viktorin <pvikt...@redhat.com> wrote: > On 11/05/2017 08:39 PM, Troy Curtis Jr wrote: > > So, do upstream contributions count toward Parselmouth badges? ;) > > I'm afraid the way they're set up now, they're just for the Fedora > packages – mainly because I don't really want to get in the business of > reviewing how each upstream contribution affected Fedora. > > Should that be changed? > I don't necessarily think that, I was just wondering. I could see how doing so would be a much bigger scope. Plus there isn't a shortage of opportunity in just packages! Troy ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Extension Build Question/Recommendation
I'd like to know what everyone's take on the best way to build python extensions for both python2 and python3 when the upstream build system can only build for one at time. The path I took for the gpsd update I submitted was to use two independent source trees, then build one for python2 and another for python3. But of course if the software is much more than just the python extensions, it is rebuilding a lot of the same code, with the same result. This could be considered a bit wasteful of CPU and disk space, and certainly increases build time. The only other option I could come up with would be to build for python2, install that, and then within the install section, reconfigure with python3 and rebuild (which should hopefully only rebuild the python related parts), and finally install again with the python3 configured setup. One pitfall I see with this method is the potential need to manually clean out certain python2 based generated files if the reconfigure isn't enough. Plus this results in building in the install section, which seems a little bit off. IMHO the first option is better. Sure, it wastes some CPU cycles and disk space, as well as increases package build time. However, it seems less prone to needing manual tweaks, provides a much cleaner distinction between the two build configs, and would make it easier to enable/disable the two variants as desired. But that is just my opinion, I'm curious what the Python SIG consensus is. Troy ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
portingdb
What is the story with the python3 portingdb instance ( http://fedora.portingdb.xyz/)? It's been down for quite a while now. Troy ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Python 3 porting Bugzilla guidance
On Mon, Sep 18, 2017 at 7:01 AM Petr Viktorinwrote: > It's only automatic for Bugzilla. If upstream is not using the Fedora/RH > bugzilla (which it shouldn't, really), a URL for the upstream discussion > needs to be added manually. And of course you can open a portingdb > ticket for that. > > > Nowadays I don't want portingdb to have too much info about upstream, > because: > - Upstream discussions for a projects are usually not hard to find. > - Bugzilla is Fedora-specific, so people from other OSs won't look there. > - portingdb is mainly used by the Fedora Python SIG; both upstreams and > other Fedorans aren't likely to look there. > > So I prefer portingdb having just an URL for the upstream discussion – > and even that isn't needed if interested people can easily find that > discussion. > > So if there are pending issues, patches, or merge requests upstream related to the python3 porting effort there should be a portingdb ticket created requesting a link to the upstream discussion/status be added? And I should *not* create a bugzilla ticket blocking https://bugzilla.redhat.com/show_bug.cgi?id=1322027 like I did with https://bugzilla.redhat.com/show_bug.cgi?id=1492382 ? Or perhaps both should/could be done as perhaps they are used by separate teams tracking different status? Just trying to get a handle on the preferred route. Thanks, Troy > > Once there's a py3-compatible release upstream, it's enough to open a > bugzilla for the Fedora package and link it to the tracking bug (see > [Python 3 Bug Filing]). Then portingdb will eventually update. > > > [Python 3 Bug Filing]: > https://fedoraproject.org/wiki/User:Pviktori/Python_3_Bug_Filing > > -- > Petr Viktorin > ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Package submission question
On Mon, Sep 4, 2017 at 3:54 AM Petr Viktorin <pvikt...@redhat.com> wrote: > On 09/04/2017 06:21 AM, Troy Curtis Jr wrote: > > I have a version of the gpsd package which I believe addresses this > > ticket https://bugzilla.redhat.com/show_bug.cgi?id=1390812. I've been > > looking around about the right way to submit. I thought it would be by > > using a pull request from within the pagure instance at > > src.fedoraproject.org <http://src.fedoraproject.org>. However, I cannot > > authenticate with my ssh key. There is no where to add it within > > pagure, and my FAS key doesn't seem to be sufficient. So perhaps this > > isn't they way? Then I was reading through > > > http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_Review_Request > > , but it seems a bit geared toward brand new packages, so I was not sure > > if that was in fact the proper coarse. > > > > I'd appreciate any pointers as to the proper direction to get this > > updated package updated. In the meantime, I'll fix the rpmlint warnings > > I just found! > > That shouldn't be happening. > What's your FAS username? > troycurtisjr > > If you can push the changes to another public Git repository (e.g. > GitHub), that could be a workaround while we get Pagure access sorted out. > Ok so Pagure is the right way to go then. I tried importing my key again, but I'm still getting denied. I can use the same key on a different linux host as well as with gitlab.com, so I'm fairly confident my local configuration is correct. I assume this is unrelated, but I also can't seem to tie my FAS account correctly to the For the time being then, I've pushed my changes to https://gitlab.com/troycurtisjr/fedora-pkg-gpsd.git under the 'python2-packaging' branch for review. Additionally, I used copr to build for several releases, which you can find at https://copr.fedorainfracloud.org/coprs/troycurtisjr/gpsd/build/597872/ -- Troy Curtis > > -- > Petr Viktorin > ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Package submission question
I have a version of the gpsd package which I believe addresses this ticket https://bugzilla.redhat.com/show_bug.cgi?id=1390812. I've been looking around about the right way to submit. I thought it would be by using a pull request from within the pagure instance at src.fedoraproject.org. However, I cannot authenticate with my ssh key. There is no where to add it within pagure, and my FAS key doesn't seem to be sufficient. So perhaps this isn't they way? Then I was reading through http://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_Review_Request , but it seems a bit geared toward brand new packages, so I was not sure if that was in fact the proper coarse. I'd appreciate any pointers as to the proper direction to get this updated package updated. In the meantime, I'll fix the rpmlint warnings I just found! Thanks, Troy ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Re: Question about working with upstream vs patches
On Sat, Sep 2, 2017 at 7:40 AM Miro Hrončok <mhron...@redhat.com> wrote: > On 2.9.2017 05:53, Troy Curtis Jr wrote: > > Howdy, > > Hi Troy, > > > I'd like to help work toward the Fedora move toward Python 3. There is > > lots of good information out there about much of the process, but I did > > have a few questions about how you like to do things, and the proper > > work-flow. > > This is always a great thing to hear. Welcome. Hopefully we will be able > to help you with your questions. > > > If I start working on a particular package, should I mention as such in > > the associated porting bugtracker ticket? I could see it either way, > > either it needless clutters the ticket comments, or it is helpful for > > the next guy to pick a different package. > > It's always helpful to say: "Hi, I'm going to work on this." It > eliminates the possibility that some work is being done by multiple > persons at the same time. > > Also, it allows others to say things like: "Hey Troy, are you still > working on this? What's your status?" > > Don't worry about needless cluttering. Any information relevant to the > ticket is good. Even if it says: "I'm still interested in this, but I > haven't been able to progresses trough XYZ, as it seems I'm stuck at ABC." > > Sounds great, I'll put a comment on the ticket. > > I already started looking at gpsd, since I've had some experience with > > it, and it is bound to be challenging! I was proven right pretty > > quickly. It is all perfectly workable, but I wanted to know the general > > expectation. For changes to python modules/scripts themselves to > > support python 3, does this need to flow through upstream in all cases? > > In 99.98% cases, it has to go trough upstream. I can see a situation, > where patches are being reviewed upstream, likely to be accepted, but we > need this in Fedora ASAP, so patches are applied in Fedora before > accepted upstream. But that should only happen if this package is > blocking other important packages. I think we did this with > python-yubikey (not quite sure). > > Applying Python 3 compatibility patches downstream only (i.e. only in > Fedora, not yet proposed to upstream) is strongly discouraged. I would > only see a fit there if there is already a python3-xyz package and in an > update, it loses Python 3 compatibility by accident, users start filling > bugs and everything is broken. In that case, I would see a situation > where patching downstream first and proposing to upstream immediately > after is a good way. > > But if the python3-xyz package is not yet in Fedora, always go upstream > first. > > Doing Python 3 compatibility patches downstream only you are basically > maintaining a fork. If you want to do that (sometimes you do, because > upstream is dead or doesn't want Python 3), there are better places to > maintain forks than Fedora spec + patches. This happened with > python-ldap vs. python-pyldap (fork is maintained on GitHub). > > Makes perfect sense, I am just used to seeing the pile of patches in RPMs. I'll certainly start working with upstream on it. > > > Most of my packaging experience has been with the enterprise distros, > > and there are always loads of patches carried along with the sources, > > but in this case do you require an official release from the upstream > > project with the necessary changes? > > Official release is the best. If the release will come late and the > package is blocking something, taking patches form upstream version > control system (e.g. git) and applying them to get Python 3 support > might be applicable. (It happened in the past.) This always depends on > the reason. > > Consider those situations: > > * Next release of xyz will be in 3 weeks and will bring Python 3 support. > > * Next release of abc might happen in a year, if there are no serious > problems. Python 3 support is in git master and will be only officially > released in the next release. There are 5 packages that require abc and > are Python 3 ready, only waiting for abc. > > Those are obviously different. Always apply common sense. > > > I certainly plan on providing all the changes upstream, but the last > > release was almost 2 years ago, so I'm not certain when a new one might > > be expected (the project is still active though). > > Get the patches to upstream. If accepted, talk to them about releasing. > If they are reluctance to do a release soon, revisit this question. > > > Hope my answers were helpful. Find me or others on #fedora-python IRC > channel if you need real time clarifications. (Or continue > asynchronously
Question about working with upstream vs patches
Howdy, I'd like to help work toward the Fedora move toward Python 3. There is lots of good information out there about much of the process, but I did have a few questions about how you like to do things, and the proper work-flow. If I start working on a particular package, should I mention as such in the associated porting bugtracker ticket? I could see it either way, either it needless clutters the ticket comments, or it is helpful for the next guy to pick a different package. I already started looking at gpsd, since I've had some experience with it, and it is bound to be challenging! I was proven right pretty quickly. It is all perfectly workable, but I wanted to know the general expectation. For changes to python modules/scripts themselves to support python 3, does this need to flow through upstream in all cases? Most of my packaging experience has been with the enterprise distros, and there are always loads of patches carried along with the sources, but in this case do you require an official release from the upstream project with the necessary changes? I certainly plan on providing all the changes upstream, but the last release was almost 2 years ago, so I'm not certain when a new one might be expected (the project is still active though). Thanks, Troy Curtis ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org