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/c7a9aa2e7b0b1d9d621ac60f...
<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/#_provid...
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