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
<snip>
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
