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...
I also played around pith setuptools' `provide` only to learn
later on that pip
ignores it entirely (as well as `obsoletes`, which is deprecated). So, the
pyproject-rpm-macros are probably not honoring that either.
> For example %pyproject_buildrequires queries Python for installed packages
> (hence it reads the packaged dist-info/egg-info metadata) and it will see
> nose is not installed.
>
> It will then query dnf to install python3dist(nose). dnf will install pynose.
>
> %pyproject_buildrequires will see nose is not installed. It will query dnf to
> install python3dist(nose) again. dnf will install nothing.
>
> The %pyproject_buildrequires phase will end prematurely when dnf installs
> nothing.
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...
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok