help wanted with modern Python packaging macros
(%generate_buildrequires, %tox)
by Felix Schwarz
Hi,
I wanted to update python-dns-lexicon. Version 3.4 uses poetry and tox so I
thought it would be a good idea to get a grip on %generate_buildrequires, %tox
etc.
Unfortunately I'm a bit stuck at the moment. Maybe this is just because I'm
starring for too long on some spec file (and probably my knowledge of
tox+macros is lacking).
I pushed the current state to:
https://src.fedoraproject.org/fork/fschwarz/rpms/python-dns-lexicon/commi...
My main problem is shown at the end of this mail: Somehow the Python extras
subpackage name is bad but I don't know how to debug this (without spending a
lot of time).
Additionally (but lower priority) just using %tox in %check fails (I think it
tries to download dependencies?).
Any help/pointers appreciated.
Felix
$ fedpkg --release=f33 mockbuild
…
Obsoletes: python-dns-lexicon < 3.4.0-1.fc33
Processing files: python3-dns-lexicon+easyname-3.4.0-1.fc33.noarch
Error: The package name contains an extras name `easyname` that was not found
in the metadata.
Check if the extras were removed from the project. If so, consider removing
the subpackage and obsoleting it from another.
error: Dependency tokens must begin with alpha-numeric, '_' or '/': ***
PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR ***
Error: The package name contains an extras name `easyname` that was not found
in the metadata.
Check if the extras were removed from the project. If so, consider removing
the subpackage and obsoleting it from another.
error: Dependency tokens must begin with alpha-numeric, '_' or '/': ***
PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR ***
Provides: python-dns-lexicon+easyname = 3.4.0-1.fc33
python3-dns-lexicon+easyname = 3.4.0-1.fc33 python3.9-dns-lexicon+easyname =
3.4.0-1.fc33
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests)
<= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Obsoletes: python-dns-lexicon+easyname < 3.4.0-1.fc33
RPM build errors:
absolute symlink: /usr/bin/lexicon-3 -> /usr/bin/lexicon-3.9
Dependency tokens must begin with alpha-numeric, '_' or '/': ***
PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR ***
Dependency tokens must begin with alpha-numeric, '_' or '/': ***
PYTHON_EXTRAS_NOT_FOUND_ERROR___SEE_STDERR ***
Finish: rpmbuild python-dns-lexicon-3.4.0-1.fc33.src.rpm
Finish: build phase for python-dns-lexicon-3.4.0-1.fc33.src.rpm
3 years, 5 months
Automated Python packaging?
by Peter Oliver
Thereʼs a Python module Iʼd like to package for Fedora. I made a start on Copr, but I rapidly got lost in a maze of missing dependencies and broken builds.
OTOH, running `pip install` takes seconds and everything just works.
I feel like someone must have come up with an easy way of building a chain of PyPI dependencies into a collection of RPMs. Am I missing a trick?
--
Peter Oliver
3 years, 5 months
RFC: Mangle Python shebangs to fully qualified interpreter (/usr/bin/pythonX.Y)
by Neal Gompa
Hey all,
An "interesting" Linux support issue at work with another Linux
distribution opened my eyes to the possibility of how badly things
would break if /usr/bin/python3 was swapped or otherwise altered by an
external force. In such a scenario where it was overridden to point to
another Python 3 interpreter that wasn't the system one, things would
break pretty badly.
Now that we've been moving toward a model where it becomes possible
for first-party or third-party multi-Python RPMs, I'm wondering if it
would make sense to evolve the shebang mangling for Python to resolve
to the fully qualified Python interpreter path (that is,
/usr/bin/pythonX.Y instead of /usr/bin/pythonX) for packaged Python
code. Presumably this may make things easier for switching Python
versions without everything breaking, too.
In practice, I don't think this is a *huge* issue Fedora-side, since
we don't manage /usr/bin/python3 via alternatives. But I can easily
see people wanting /usr/bin/python3 to be swappable in Red Hat
Enterprise Linux, while everything is still parallel installable and
fully functional. The Python interpreter packaging even mostly
supports this now.
What do y'all think? Is this doable? Is this desirable?
--
真実はいつも一つ！/ Always, there's only one truth!
3 years, 5 months
