Idea: pynose as drop-in replacement for nose
by Sandro
Hi,
While looking into a package upgrade I came across pynose [1]. It
appears to be a drop-in replacement for nose [2], which has been
deprecated in Fedora 32 [3].
There are still quite a few packages depending on nose, that have not
yet moved away from it. The official successor to nose is nose2 [4]. But
that package does not support all of the behavior of nose.
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.
As a preliminary smoke test I built all packages depending on nose in
Copr against pynose [5]. Packages failing to build against pynose I also
built against nose [6]. I haven't checked all packages in detail yet,
but the amount packages failing appears manageable (17).
Going by [3] I suppose this would also need to go through the changes
process. If so, I'd be willing to drive that. But I could use some
help/support since this would be my first change proposal.
In a way this e-mail is kind of an informal general rehearsal.
With that said, please shoot! 🔫
[1] https://github.com/mdmintz/pynose
[2] https://github.com/nose-devs/nose
[3] https://fedoraproject.org/wiki/Changes/DeprecateNose
[4] https://github.com/nose-devs/nose2
[5] https://copr.fedorainfracloud.org/coprs/gui1ty/pynose
[6] https://copr.fedorainfracloud.org/coprs/gui1ty/nose
Cheers,
--
Sandro
FAS: gui1ty
Matrix: Penguinpee
Elsewhere: [Pp]enguinpee
5 days, 2 hours
Creating venv with latest python3.10 requires expat >= 2.6.0
by Markus Falb
Hi,
I noticed that creating virtualenvs did not work anymore with the latest python 3.10 package on Fedora 38
...snip
[root@fe60c84b08f3 /]# cat /etc/fedora-release
Fedora release 38 (Thirty Eight)
[root@fe60c84b08f3 /]# rpm -q python3.10
python3.10-3.10.14-1.fc38.x86_64
snap...
Here comes the error
...snip
[root@fe60c84b08f3 /]# python3.10 -m venv venv
Error: Command '['/venv/bin/python3.10', '-m', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.
snap...
https://www.python.org/downloads/release/python-31014/ tells us
... bundled libexpat was updated to 2.6.0 to address CVE-2023-52425...
using the fedora container for CI runs without doing global dnf update to save resources I had to update expat from
expat-2.5.0-2.fc38.x86_64
to
expat-2.6.0-1.fc38.x86_64
I wonder if there is a way to reflect that in the spec file
something like:
...snip
Requires: expat >= 2.6.0
snap...
?
All the best, Markus
1 week, 5 days
Handling --enable-experimental-jit in Python 3.13
by Miro Hrončok
Hello Pythonistas,
Python 3.13 has an experimental JIT compiler:
https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler
Enabling it is a configure (hence build-time) option.
How do we handle this in Fedora?
- We can keep it disabled, as it is experimental.
- We can enable it, but be ready to revert if it causes problems.
- We can add yet another build variant, but we already have 4 of those
(regular, debug, freethreading, freethreading-debug), so I'd rather not make it
6 (or 8, if we include freethreading+jit combinations). I don't know yet if it
would be co-installable.
Opinions?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1 week, 5 days
RFC: Django latest vs LTS maintenance plan
by Michel Lind
Hi all,
With the recent EOL of the Django 3.2 LTS series[^1], and Django being a
key component of our mailing list infra for both Fedora and CentOS, I
would like to propose the following plan to maintain Django in both
Fedora and EPEL:
- Fedora: `python-django` maintained as currently, not tracking any LTS
series
- **but** also fork off `python-django` each time it hits an LTS
series to make a new `python-djangoX.Y` (e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=2274198)
- LTS packages are introduced in Fedora first, until they either reach
EOL or no longer build, at which point they are retired in Rawhide.
See below for the EOL case.
- EPEL: we will only branch LTS packages (as is the case now, with
`python-django3` - though under the new naming scheme it should have
been `python-django3.2`)
- Handling EOL
- not an issue for `python-django` - we just keep rebasing it
- for LTS releases in Fedora, retire in Rawhide if the series will
EOL before the EOL of the upcoming Fedora release
- for LTS releases in EPEL, once it is EOL (like `python-django3`)
we mark it as `Provides: deprecated()` and retire it if there is a
replacement that works with add-on packages, *and* there is a CVE
that is not fixed
- Package ACL: cc-ing the current maintainers of python-django here.
Please let me know if
- you want to be added to the LTS packages as well
- you want to be removed from python-django
- you're not currently involved but want to help out
- I'll also add infra-sig to the ACL for the LTS packages, as in
practice they might need access to fix any issue affecting Mailman
The different Django stacks are in the process of being updated so they
can be swapped without affecting dependents, by providing and
conflicting with the virtual `python-django-impl`; not only will this
allow us to swap one Django LTS for another in EPEL when the older one
EOLs, but it also allows those with dependencies that are not qualified
for the latest Django to swap to the LTS in Fedora
Let me know if this makes sense, or if you have ideas of how to handle
some of these better.
[^1]: https://www.djangoproject.com/weblog/2024/apr/03/bugfix-release/
Best regards,
--
_o) Michel Lind (né Salim)
_( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
2 weeks, 4 days
%pyproject_buildrequires -r/-x: Attempt to read runtime dependencies
from pyproject.toml?
by Karolina Surma
Hello,
recently, we were suggested an improvement for %pyproject_buildrequires
-r/-x.
We could read the project's runtime dependencies (if they're not marked
as `dynamic`) from pyproject.toml [project] table directly, without
calling prepare_metadata_for_build_wheel or building the wheel to read
the dependency metadata from it.
Reading the metadata via prepare_metadata_for_build_wheel is already
quite fast, however implementing that hook is optional for the build
backends. When the hook is not available, we need to build the wheel,
which can be potentially very slow and resource-hungry (imagine building
the entire scipy project).
Metadata in pyproject.toml is standardized (PEP 621), however there is
no way of telling ahead of time if the build backend already supports
that standard.
See the details and discussion in bugzilla:
https://bugzilla.redhat.com/2261939
Maxwell has raised some valid concerns there:
- Other tools (build frontends, e.g. pip/build) call
prepare_metadata_for_build_wheel, our macros would diverge in
functionality compared to the rest of the landscape.
- pyproject.toml's [project] may not be the source of metadata that the
build backend uses. A project could switch to a build backend without
PEP 621 support (e.g. poetry-core) and forget to remove the [project] table.
- There can be potential differences between BuildRequires and Requires
generators when one generates dependencies based on the pyproject.toml
[project] table while the other on the packaged dist-info metadata.
- Using macros to build on older systems: e.g. RHEL 9's old setuptools
version silently ignores the pyproject.toml [project] table -
%pyproject_buildrequires could still pull the dependency information
from it, but the resulting package would be broken because it did not
include those in the packaged dist-info metadata.
One way to mitigate would be to make the proposed behavior opt-in only,
with the possibility to either build wheel with -w option (already
existing) or e.g. -p (now-proposed: reading from pyproject.toml) in case
backend doesn't have prepare_metadata_for_build_wheel. However, this
adds a layer of complexity for packagers and macros maintainers.
The questions we'd love your input for:
- Should %pyproject_buildrequires try to read dependencies from
pyproject.toml first and fall back to calling hooks only if that fails?
- Should %pyproject_buildrequires call the hook and try to fall
back to reading dependencies from pyproject.toml when the hook is not
availbale?
- Should this behavior exist but not be the default (explicit flag
would be required to opt-in)?
- Can you think of a better alternative than the ones described here?
Cheers,
Karolina
3 weeks, 3 days
Issues with pytest and python-pytest-postgresql
by Mikel Olasagasti
Hi all,
I'm trying to update python-pytest-postgresql (simple bump) and during
the %check phase I find the following error:
+ /usr/bin/pytest --postgresql-exec=/usr/bin/pg_ctl -k 'not docker' --no-cov
(...)
File "/builddir/build/BUILDROOT/python-pytest-postgresql-6.0.0-1.fc41.x86_64/usr/lib/python3.12/site-packages/pytest_postgresql/plugin.py",
line 67, in pytest_addoption
parser.addoption(
File "/usr/lib/python3.12/site-packages/_pytest/config/argparsing.py",
line 104, in addoption
self._anonymous.addoption(*opts, **attrs)
File "/usr/lib/python3.12/site-packages/_pytest/config/argparsing.py",
line 385, in addoption
raise ValueError("option names %s already added" % conflict)
ValueError: option names {'--postgresql-exec'} already added
What I found is that once the postgresql plugin is loaded it conflicts
with the tests of the module.
Any advice on how to solve this issue?
Best regards,
Mikel
3 weeks, 4 days
