Dist failure for Fedora, CentOS, EPEL about python-pathspec

[cpburnz]

I'll work on restoring support for setup.py tonight so that it'll work as it previously did. After briefly looking at setuptools's docs, it should be simple.

[cpburnz]

Hi @adrienverge,

I have a very short blurb in README.rst.

You'll need to have build (>=0.6.0, tested with 0.8.0), setuptools (>=40.8.0), and pip installed.

You can build both the source (sdist) and binary (wheel) distributions using python -m build. This will create dist/pathspec-{version}-py3-none-any.whl and dist/pathspec-{version}.tar.gz. To create just the sdist, run python -m build --sdist (the equivalent to python setup.py sdist).

You can install the sdist using pip install dist/pathspec-{version}.tar.gz.

I did extract out the tests from pathspec/tests/ to tests/ in the root of the project so they're no longer installed along with pathspec. If that causes an issue with testing, I can move them back.

Keep in mind you need to run Python >=3.7 so you may need to adjust which python executable you use. On Ubuntu it'd be python3 or python3.7 if the python-is-python3 isn't installed. I'm not sure how Fedora versions Python packages.

[adrienverge]

Thanks for your answer @cpburnz.

To my knowledge pip cannot be used to install files to the system (which is a needed step to create RPM packages, usually done with setup.py install) without accessing internet or trying to manage dependencies itself, which isn't permitted when creating RPM packages.

I spent 90 more minutes trying to get something working, but I have to give up.

For reference if someone wants to maintain the package for Fedora, EPEL, etc.:

• pip install --target=%{buildroot}%{python3_sitelib} . could be used if pip didn't try to reinstall setuptools and manage dependencies itself (although it's kind of dirty to use pip for this purporse ; %py3_install or %pyproject_install should be preferred).
• I didn't find a way to get tox (nor the %tox macro) working, they seem to rely on setup.py.
• I leave my modified python-pathspec.spec file attached.

[Jackenmen]

It's not my project so it might come across as a bit rude but it seems to me like it's the author of the issue who should be modernizing how they use Python packaging rather than the author of the package switching back to the old methods.

Running setup.py as a script is strongly discouraged and most of its subcommands are deprecated, see:

• note in setuptools documentation: https://setuptools.pypa.io/en/latest/userguide/quickstart.html#setuppy-discouraged
• Why you shouldn't invoke setup.py directly written by Paul Ganssle

I don't use or package for Fedora but making packages for projects using PEP 517 build system surely must be an already solved problem? Quick googling shows me that the mentioned %py3_install macro (as well as not mentioned %py3_build macro) is superseded by pyproject macros? https://src.fedoraproject.org/rpms/pyproject-rpm-macros

Yes, restoring support for setup.py should actually just simply be adding setup.py with these contents as everything is already in pyproject.toml:

from setuptools import setup

setup()

and that could be an alright solution until the distro package maintainers solve problems with their packages but I think it's unfair for distro maintainers to hold back the progress forever.

[cpburnz]

@adrienverge The latest commit has setup.py in place, and in my testing (not on Fedora) the old setup.py commands work. Can you test this to see if it works on your end?

At the moment setuptools >=61.0.0 is required in order for setup.py to read the pyproject.toml (replacement for setup.cfg). Does this version dependency on setuptools present a problem for the distros you're packaging on? If it is a problem, I can remove this requirement and just regenerate a setup.cfg from the pyproject.toml when I publish releases.

[cpburnz]

@jack1142 It's relatively trivial for me to reintroduce support for legacy installation through setup.py. I don't have a problem supporting it until those distros can get their upgrade path clear, wherever the root problem may lie. @adrienverge has already wasted a few hours working with the new method.

[adrienverge]

@jack1142 you're not rude 🙂 and I agree with your point of view: I would prefer shifting to newest standards. Indeed the "new" way to go is using pyproject macros, like %pyproject_install, as I mentionned. Unfortunately this doesn't work, not out-of-the-box nor with 1-2 hours of work. To be honest, someone will more Python-packaging skills than me could make it (feel free to try, or to share a command other than pip to cleanly install the package inside /usr/lib/python3.10/site-packages/).

@cpburnz thanks a lot! Your latest commit on master works like a charm for Fedora ≥37 (unstable).
As you suspected, the setuptools >=61.0.0 requirement is a problem for currently-supported versions, where setuptools is packaged as 57.4.0 (Fedora 35), 59.6.0 (Fedora 36), 53.0.0 (EPEL 9). There, pathspec is incorrectly installed inside /usr/lib/python3.10/site-packages/UNKNOWN-0.0.0-py3.9. It would be awesome to ship a setup.cfg (just for some time, while distros update their setuptools).

[cpburnz]

@adrienverge The latest commit now has a setup.cfg and only a dependency on setuptools >=40.8.0.

[adrienverge]

Tested on Fedora 35, Fedora 36 and EPEL 9: it works 🎉

Thank you for this fast adjustment. I'll update packages on next tag.

[cpburnz]

@adrienverge v0.10.1 has been released.

[adrienverge]

Thank you @cpburnz! I created packages for Fedora and EPEL.