Adding python3.10dist(pp) to python-ppft

[Ankur Sinha]

Hi folks,

I was looking to unretire the unmaintained python-pp because some neuro
packages still use it but then was reminded by @music that we already
provide python-ppft which is a maintained fork and drop-in replacement
for pp.

https://github.com/uqfoundation/ppft

Currently python3-ppft provides these:

$ rpm -q --provides python3-ppft
python-ppft = 1.6.6.4-2.fc35
python3-ppft = 1.6.6.4-2.fc35
python3.10-ppft = 1.6.6.4-2.fc35
python3.10dist(ppft) = 1.6.6.4
python3dist(ppft) = 1.6.6.4

Can we also provide all these for `pp` so that packages in Fedora that
require pp automatically use ppft?

I tried adding `%py_provides pp` to python3-ppft, and while that does
add a few of these, it does not add the python3.10dist(pp) or
python3dist(pp) ones (which are autogenerated from the metadata?):

$ rpm -q --provides -p ./results_python-ppft/1.6.6.4/3.fc36/python3-ppft-1.6.6.4-3.fc36.noarch.rpm 
python-pp = 1.6.6.4-3.fc36
python-ppft = 1.6.6.4-3.fc36
python3-pp = 1.6.6.4-3.fc36
python3-ppft = 1.6.6.4-3.fc36
python3.10-pp = 1.6.6.4-3.fc36
python3.10-ppft = 1.6.6.4-3.fc36
python3.10dist(ppft) = 1.6.6.4
python3dist(ppft) = 1.6.6.4

Would there be a way to include these machine readable provides too
since these forms are used by other packages in the automatically
generated requires etc. (if this is the right thing to do)?

I guess the alternative would be that every package that requires pp be
patched to require ppft, but tweaking a single python-ppft package would
be less work. :)

[Petr Viktorin]

On 07. 12. 21 22:42, Ankur Sinha wrote:
> Hi folks,
>
> I was looking to unretire the unmaintained python-pp because some neuro
> packages still use it but then was reminded by @music that we already
> provide python-ppft which is a maintained fork and drop-in replacement
> for pp.
>
> https://github.com/uqfoundation/ppft
>
> Currently python3-ppft provides these:
>
> $ rpm -q --provides python3-ppft
> python-ppft = 1.6.6.4-2.fc35
> python3-ppft = 1.6.6.4-2.fc35
> python3.10-ppft = 1.6.6.4-2.fc35
> python3.10dist(ppft) = 1.6.6.4
> python3dist(ppft) = 1.6.6.4
>
> Can we also provide all these for `pp` so that packages in Fedora that
> require pp automatically use ppft?
>
> I tried adding `%py_provides pp` to python3-ppft, and while that does
> add a few of these, it does not add the python3.10dist(pp) or
> python3dist(pp) ones (which are autogenerated from the metadata?):
>
> $ rpm -q --provides -p ./results_python-ppft/1.6.6.4/3.fc36/python3-ppft-1.6.6.4-3.fc36.noarch.rpm
> python-pp = 1.6.6.4-3.fc36
> python-ppft = 1.6.6.4-3.fc36
> python3-pp = 1.6.6.4-3.fc36
> python3-ppft = 1.6.6.4-3.fc36
> python3.10-pp = 1.6.6.4-3.fc36
> python3.10-ppft = 1.6.6.4-3.fc36
> python3.10dist(ppft) = 1.6.6.4
> python3dist(ppft) = 1.6.6.4
>
> Would there be a way to include these machine readable provides too
> since these forms are used by other packages in the automatically
> generated requires etc. (if this is the right thing to do)?
>
> I guess the alternative would be that every package that requires pp be
> patched to require ppft, but tweaking a single python-ppft package would
> be less work. :)

Hi,
These are generated from Python metadata, e.g. install_requires in 
setuptools: 
https://github.com/uqfoundation/ppft/blob/a4dd5832103512f6df717637b03fb507a0...

If you only add the RPM provides, tools that read the Python-specific 
metadata might complain about not finding pp. And unfortunately Python 
packaging doesn't have good support for "virtual provides" 
(Provides-Dist) yet.

So it looks like it would be best to patch setup.py (or equivalent) in 
all dependent packages. And perhaps push the change upstream, if ppft is 
better than pp. (I don't know anything about these packages.)

[Ankur Sinha]

On Thu, Dec 09, 2021 10:44:37 +0100, Petr Viktorin wrote:
> <snip>
> Hi,

Hi Petr,
> These are generated from Python metadata, e.g. install_requires in
> setuptools: https://github.com/uqfoundation/ppft/blob/a4dd5832103512f6df717637b03fb507a0...
>
> If you only add the RPM provides, tools that read the Python-specific
> metadata might complain about not finding pp. And unfortunately Python
> packaging doesn't have good support for "virtual provides" (Provides-Dist)
> yet.
>
> So it looks like it would be best to patch setup.py (or equivalent) in all
> dependent packages. And perhaps push the change upstream, if ppft is better
> than pp. (I don't know anything about these packages.)

Thanks for confirming. We thought so too. So I'll add a conflicts in
ppft instead to ensure that pp isn't packaged up in the future. The two
modules do provide the same files too, so they cannot both be installed.