Macronize %pytest
by Miro Hrončok
Hello Python packagers,
since there is no upstream supported universal test invocation for Python
(`python setup.py test` is deprecated and the de-facto-standard `tox` doesn't
always do what we want in RPM's %check and/or is not always used by upstreams)
and a lot of upstreams use pytest, I'd like to propose a %pytest macros, for
standardizing the way pytest is run.
Usage:
%check
%pytest
Or with options passed to pyets:
%check
%pytest -v -m "not network" tests/
(Here ends the tl;dr version.)
Why not just use `pytest` or `%{python3} -m pytest` instead of `%pytest`?
We want to *test the code we ship*. In the general case this involves:
1. Prepending sys.path with %{buildroot}%{python3_sitelib} (and/or sitearch)
2. Prepending $PATH with %{buildroot}%{_bindir}
3. Ensuring $PWD is not in sys.path
So the idea is (untested):
%pytest_cmd /usr/bin/pytest
%pytest %{expand:
PYTHONPATH="${PYTHONPATH:-%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib}}"
\
PATH="%{buildroot}%{_bindir}:$PATH" \
%pytest_cmd
}
Where PYTHONPATH solves (1), PATH solves (2) and using `/usr/bin/pytest` over
`%{python3} -m pytest` kinda solves (3).
I say "kinda" because using `python -m pytest` explicitly adds $PWD to sys.path,
but using `pytest` doesn't always prevent it.
https://docs.pytest.org/en/latest/usage.html#calling-pytest-through-pytho...
I've been trying to completely solve (3) in my head in a general way, but it
always involves `cd`ing to a temporary directory before running the tests, but
plenty of test suites cannot handle that gracefully.
Unfortunately Python interpreter doesn't have a flag that says "don't add
current directory to sys.path, but respect $PYTHONPATH". In the long term, we
might propose to add it.
Where to have the macro defined? (Skip this part if not interested.)
I was thinking:
a) pytest package
b) pytest subpackage (required if rpm-build)
c) python3-rpm-macros
d) python-rpm-macros
e) pyproject-rpm-macros
And here is the pros and cons:
a+) self contained, can change with upstream if needed
a+) always present with pytest
a-) pytest must co-own macro dir or depend on rpm-build
b+) same as a+, but not a-
b-) additional layer of complexity
c+) easy
c+) the macro doesn't need to require pytest, can be used with arbitrary command
c+) can be generalized to non-pytest later if desired
c-) when pytest CLI changes significantly, we need to change it in different
package (but we are not using pytets CLI now at all, just Python/Shell
environment variables)
c~) technically not always present with pytest, but always present with
python3-devel
d+-) same as (c)
d-) the macro uses python3 specific things
e+) the new fancy macros are there
e-) the other macros from there (actually pyproject related) are not required
for this
e-) not always present with pytest nor python3-devel
Hence, I'd go with (c) python3-rpm-macros.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 11 months
- 5
- 6
Rawhide python-rpm-generators news: small speedup + %python_provide not needed in most cases
by Miro Hrončok
Hello Python packagers.
I have just updated python-rpm-generators to python-rpm-generators-11-1.fc33 in
Rawhide. It uses some fresh stuff from RPM 4.16 and will not be backported to
older releases.
The python(abi) requirement is now added from a RPM Lua macro, instead of by
executing a Shell script. This is a bit faster especially for packages with a
lot of files. For 10 000 files in one package, the speedup is roughly from ~80
to ~2 seconds (time of the entire package build incl. creating the files from a
Python script). That is a lot, but most of the real packages have much less
files, so I am afraid you won't feel it.
More importantly, %python_provide is not needed for package names.
Until now, we needed to this:
%package -n python3-foo
...
%{?python_provide:%python_provide python3-foo}
This adds automatic provides "python-foo" (and since recently, also
"python38-foo" for forwards/backwards compatibility with EL). This now happens
automagically. Any package called "python3-..." will have those provides added
implicitly by the Python generators when they are in the buildroot
(python3-devel brings those in, so for Python packages this means always).
This automation was possible due to the speedup mentioned above, doing it the
pre-RPM.16 way would be very slow, because the generator is called for every
packaged file (which is still the case now, but it can now be a Lua macro). The
~2 seconds from above include this new feature.
There are 2 cases where manual %python_provide calls are still needed:
1. Metapackages without files
No files => no dependency generator. (I recommend to %ghost the
dist-info/egg-info directory in such packages to workaround this -- we plan to
add more good stuff regarding Python [extras] that will require this anyway.)
2. Virtual provides
The dependency generator can see the (sub)package's name, but not any other
virtual provides. When you do:
%package -n python3-%{pypi_name}
Provides: python3-%{legacy_name} = %{version}-%{release}
You are still supposed to add:
%{?python_provide:%python_provide python3-%{legacy_name}}
(Also note that %python_provide adds obsoletes for older python-foo versions,
that was useful when we renamed everything from python-foo to python2-foo and
when we changed the "default" from python2- to python3-. We are keeping the
Obsoletes in the macro (for now), but I have decided to not automatically
generate the Obsoletes based on the package name. A) I don't consider them
really needed in Fedora 33 any more and B) an idea of implicit obsoletes doesn'T
sound very intriguing to me. This is a decision that may be revisited later if
it's bringing unforeseen trouble.)
You don't need to to actively remove the macro from your spec files, it does no
harm. If you prefer to maintain a single spec, keep it there until Fedora 32
goes EOL (and EPEL 8 if that's your target). The guidelines always recommended
using it the safe way (%{?python_provide:...}), so even if it ceases to exist in
the future, it can remain in specs. There is no plan to remove it in any near or
distant future, as it is still needed for the virtual provides. The generators
also use it internally (for DRY and consistent results).
If you'll get into trouble because of this, let us know and we'll fix it.
I'll make a note for myself to update the Python packaging guidelines.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 11 months
- 2
- 4
Should alternatives scriptles use %posttrans instead of %post?
by Miro Hrončok
Hi. Our current alternatives guidelines are very brief, but there are some
examples with %post scriptlets.
I've followed the examples when creating alternatives for mercurial, but now
I've discovered a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1831562
Running transaction
Preparing : 1/1
Installing : mercurial-lang-5.2-4.fc32.x86_64 1/3
Installing : mercurial-py2-5.2-4.fc32.x86_64 2/3
Running scriptlet: mercurial-py2-5.2-4.fc32.x86_64 2/3
failed to link /usr/bin/hg -> /etc/alternatives/hg: /usr/bin/hg exists and it is
not a symlink
failed to link /usr/bin/hg-ssh -> /etc/alternatives/hg-ssh: /usr/bin/hg-ssh
exists and it is not a symlink
Obsoleting : mercurial-4.9-2.fc31.x86_64 3/3
Running scriptlet: mercurial-4.9-2.fc31.x86_64 3/3
Verifying : mercurial-lang-5.2-4.fc32.x86_64 1/3
Verifying : mercurial-py2-5.2-4.fc32.x86_64 2/3
Verifying : mercurial-4.9-2.fc31.x86_64 3/3
Should the update-alternatives scriptlet be in %posttrans instead?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 years, 11 months
- 1
- 0