Re: RFC: Django latest vs LTS maintenance plan
On Fri, Apr 12, 2024 at 12:53:52AM +0200, Miro Hrončok wrote: > > > On 11. 04. 24 22:41, Michel Lind wrote: > > The different Django stacks are in the process of being updated so they > > can be swapped without affecting dependents, by providing and > > conflicting with the virtual `python-django-impl`; not only will this > > allow us to swap one Django LTS for another in EPEL when the older one > > EOLs, but it also allows those with dependencies that are not qualified > > for the latest Django to swap to the LTS in Fedora > > I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: > pytohn3dist(django)`? > Oh good point, that would work too. We'd still need to come up with names for the bash-completion and doc subpackages though. Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ 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: RFC: Django latest vs LTS maintenance plan
On 11. 04. 24 22:41, Michel Lind wrote: The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: pytohn3dist(django)`? -- 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
RFC: Django latest vs LTS maintenance plan
Hi all, With the recent EOL of the Django 3.2 LTS series[^1], and Django being a key component of our mailing list infra for both Fedora and CentOS, I would like to propose the following plan to maintain Django in both Fedora and EPEL: - Fedora: `python-django` maintained as currently, not tracking any LTS series - **but** also fork off `python-django` each time it hits an LTS series to make a new `python-djangoX.Y` (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2274198) - LTS packages are introduced in Fedora first, until they either reach EOL or no longer build, at which point they are retired in Rawhide. See below for the EOL case. - EPEL: we will only branch LTS packages (as is the case now, with `python-django3` - though under the new naming scheme it should have been `python-django3.2`) - Handling EOL - not an issue for `python-django` - we just keep rebasing it - for LTS releases in Fedora, retire in Rawhide if the series will EOL before the EOL of the upcoming Fedora release - for LTS releases in EPEL, once it is EOL (like `python-django3`) we mark it as `Provides: deprecated()` and retire it if there is a replacement that works with add-on packages, *and* there is a CVE that is not fixed - Package ACL: cc-ing the current maintainers of python-django here. Please let me know if - you want to be added to the LTS packages as well - you want to be removed from python-django - you're not currently involved but want to help out - I'll also add infra-sig to the ACL for the LTS packages, as in practice they might need access to fix any issue affecting Mailman The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora Let me know if this makes sense, or if you have ideas of how to handle some of these better. [^1]: https://www.djangoproject.com/weblog/2024/apr/03/bugfix-release/ Best regards, -- _o) Michel Lind (né Salim) _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ 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: Idea: pynose as drop-in replacement for nose
On 11-04-2024 15:30, Sandro wrote: I see "# Package doesn't provide any tests" in the %check section. That certainly feels a bit dodgy. This successor of a test framework decided to ditch all of the tests it used to have? That is certainly a red flag. More like a chicken and egg story, maybe? If I were to provide a testing framework, I'd very much like to use that testing framework for testing. Anyway, I'll contact upstream asking them about it. It's the least I can do. I'll also ask about the documentation link on PyPI, which points to the RTD page of ye olde . Upstream uses GitHub Actions for testing. I haven't looked into how those are set up. Apparently they also test with pynose on SeleniumBase (same maintainer, see elsewhere in this thread). While this still not provides us with the ability to test downstream, all tests I've run while investigating the feasibility of my idea so far haven't brought up any issues. If anyone wants to chime in, here is the ticket: https://github.com/mdmintz/pynose/issues/25 Last but not least, the documentation link on PyPI was fixed right away and will be in the next release. -- Sandro -- ___ 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: Idea: pynose as drop-in replacement for nose
On 11-04-2024 15:49, Ben Beasley wrote: For a proposed nose successor, pynose doesn’t seem to have gained much community traction so far: it has seven stars on GitHub[1] (compared to 770 for nose2, which itself was never that widely adopted and has fewer than ten dependent packages in Fedora); and the imperfect but fairly useful reverse dependency index at Wheelodex[2] shows only three packages that explicitly depend on it. Well, Wheelodex doesn't show pysb. They have just switched from nose to pynose. When looking into updating the package to the latest release the noses were no longer aligned (pun intended). That's how I started looking into pynose. As far as I can tell, pynose exists because SeleniumBase[3] found it easier to fork nose than to port away from it. I’m *definitely* not saying we should only package things with a bunch of GitHub stars, but I do have some concerns about whether or not pynose is going to remain a generally-useful project in the medium-to-long term. I think you are right there. The current maintainer of pynose is also a/the maintainer of SeleniumBase. Currently, pynose is seeing regular releases - seven since May 2023. When I just inquired regarding unit tests, I received a response within minutes. This might just be coincidence. But it shows the project is alive. Regarding usefulness, almost all packages in Fedora still depending on nose worked out of the box when I tested with a build of pynose mimicking nose also in the Python meta data. Two packages I couldn't test since they are currently FTBFS. One package, pycdio, is using `%python3 setup.py nosetests`. I have not yet looked into why that works with nose but not with pynose. But that line could simply be changed back to `nosetests -v`. I think the takeaway here is swapping an unmaintained package for a maintained package. How widely it will get adopted seems lees important to me. The future will tell. [1] https://github.com/mdmintz/pynose/stargazers [2] https://www.wheelodex.org/projects/pynose/rdepends/ [3] https://github.com/seleniumbase/SeleniumBase -- Sandro -- ___ 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: Idea: pynose as drop-in replacement for nose
For a proposed nose successor, pynose doesn’t seem to have gained much community traction so far: it has seven stars on GitHub[1] (compared to 770 for nose2, which itself was never that widely adopted and has fewer than ten dependent packages in Fedora); and the imperfect but fairly useful reverse dependency index at Wheelodex[2] shows only three packages that explicitly depend on it. As far as I can tell, pynose exists because SeleniumBase[3] found it easier to fork nose than to port away from it. I’m *definitely* not saying we should only package things with a bunch of GitHub stars, but I do have some concerns about whether or not pynose is going to remain a generally-useful project in the medium-to-long term. [1] https://github.com/mdmintz/pynose/stargazers [2] https://www.wheelodex.org/projects/pynose/rdepends/ [3] https://github.com/seleniumbase/SeleniumBase On 4/11/24 9:17 AM, Miro Hrončok wrote: On 11. 04. 24 15:05, Sandro wrote: On 11-04-2024 13:54, Miro Hrončok wrote: On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. That makes sense. Review is up [1]. If enough packagers adapt, I may not need to go through the changes process. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. Since predicting the future is difficult, I'll start on writing up a proposal while the package is being introduced, anyway. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514 I see "# Package doesn't provide any tests" in the %check section. That certainly feels a bit dodgy. This successor of a test framework decided to ditch all of the tests it used to have? That is certainly a red flag. -- ___ 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: Idea: pynose as drop-in replacement for nose
On 11-04-2024 15:17, Miro Hrončok wrote: On 11. 04. 24 15:05, Sandro wrote: On 11-04-2024 13:54, Miro Hrončok wrote: On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. That makes sense. Review is up [1]. If enough packagers adapt, I may not need to go through the changes process. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. Since predicting the future is difficult, I'll start on writing up a proposal while the package is being introduced, anyway. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514 I see "# Package doesn't provide any tests" in the %check section. That certainly feels a bit dodgy. This successor of a test framework decided to ditch all of the tests it used to have? That is certainly a red flag. More like a chicken and egg story, maybe? If I were to provide a testing framework, I'd very much like to use that testing framework for testing. Anyway, I'll contact upstream asking them about it. It's the least I can do. I'll also ask about the documentation link on PyPI, which points to the RTD page of ye olde . -- Sandro -- ___ 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: Idea: pynose as drop-in replacement for nose
On 11. 04. 24 15:05, Sandro wrote: On 11-04-2024 13:54, Miro Hrončok wrote: On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. That makes sense. Review is up [1]. If enough packagers adapt, I may not need to go through the changes process. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. Since predicting the future is difficult, I'll start on writing up a proposal while the package is being introduced, anyway. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514 I see "# Package doesn't provide any tests" in the %check section. That certainly feels a bit dodgy. This successor of a test framework decided to ditch all of the tests it used to have? That is certainly a red flag. -- 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
Re: Idea: pynose as drop-in replacement for nose
On 11-04-2024 13:54, Miro Hrončok wrote: On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. That makes sense. Review is up [1]. If enough packagers adapt, I may not need to go through the changes process. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. Since predicting the future is difficult, I'll start on writing up a proposal while the package is being introduced, anyway. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514 -- Sandro -- ___ 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: Idea: pynose as drop-in replacement for nose
On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. -- 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
Re: Idea: pynose as drop-in replacement for nose
On 10-04-2024 17:50, Miro Hrončok wrote:
On 10. 04. 24 17:30, Sandro wrote:
On 10-04-2024 12:04, Miro Hrončok wrote:
On 09. 04. 24 19:30, Sandro wrote:
Therefore, I'm thinking of introducing pynose as a drop in
replacement of deprecated nose. Pynose uses the same namespace as
nose, but provides python3dist(pynose). Thus adding Provides: for
nose would make it a drop-in replacement for packages currently
depending on nose.
FTR We MUST NOT add RPM Provides for python3dist(nose) unless we
package nose dist-info metadata.
Thanks for pointing that out. I was indeed experimenting with it.
Is there some documentation or example for packaging extra dist-info
metadata?
Not really, because it is a hack that should not be done if it can be
avoided.
You can see a working example in python-lark
https://src.fedoraproject.org/rpms/python-lark/c/c7a9aa2e7b0b1d9d621ac60f73c854fdcc154ab2
Agreed. If we do add python3dist(nose) it needs to work not cause more
issues. Most packages I've looked at recently have a BR for
python3-nose. That's covered by adding "%py_provides python3-nose".
But dependency resolution in %pyproject_buildrequires uses
python3dist. If the package configuration has a dependency on nose
declared, I would like that to be satisfiable, both in RPM and pip, by
installing python3-pynose.
If that is too much hassle or simply (currently) not possible, a
fallback to not providing nose at all, is also possible. In that case
more packages might need to be patched and we need to educate people
te replace dependencies on nose with pynose.
My preference at the moment is for the former.
If we are to retire python-nose at the same time, I'd do:
- have python3-pynose %py_provides (and Obsolete) python3-nose
- don't mess with dist metadata at all
That way:
- packages that use upstream requirements will need to be updated
(preferably upstream first => good)
- packages that manually BuildRequire python3-nose will likely keep
working
If the pynose package has a "nose" importable module, providing
python3-nose even follows
https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_provides_for_importable_modules
Well, `pynose` provides `nose` as an importable module, which is
installed into `%{python3_sitelib}/nose`. Since that conflicts with
python3-nose, proper Provides and Obsoletes are required, indeed.
Thanks for the example, I used that to properly provide `nose`. Building
against that package reduced the troublesome packages to one (two more
are currently FTBFS in rawhide/F40) compared to 11+2[1] when using only
`%py_provides python3-nose`.
I think that justifies carrying the "hack". Moreover, `nose` has been
dead for a long time upstream, yet we still have packages depending on
it. In a way the justification here doesn't differ very much from that
of `lark`.
I agree that maintainers of packages still depending on `nose` should
ask upstream to switch to `pynose` or some other testing framework. Yet,
I wouldn't be surprised that exactly those packages are also
un(der)maintained upstream.
While I ponder those thoughts some more, moving forward in either
direction, the next step would be writing a change proposal?
[1] Some failures were unrelated to `nose` vs. `pynose` and have been
fixed by having `pynose` require `setuptools`.
-- Sandro
--
___
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
