Looking for a new (possibly better) python-argcomplete maintainer
by Miro Hrončok
Hello.
I am the main admin of python-argcomplete in Fedora. The package is severely
outdated but works.
I don't want to maintain it, but pytest uses it for tests, so I don't want to
be retired. Is there somebody else who would take better care of it than I do?
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-argcomplete
389-ds-base-0:2.4.3-1.fc39.src
abrt-0:2.17.1-3.fc39.src
abrt-tui-0:2.17.1-3.fc39.noarch
ansible-core-0:2.15.3-1.fc40.noarch
ansible-core-0:2.15.3-1.fc40.src
azure-cli-0:2.51.0-1.fc39.src
barman-0:3.7.0-1.fc39.noarch
diffoscope-0:245-2.fc39.src
fedpkg-0:1.44-6.fc39.noarch
fedrq-0:0.10.0-2.fc39.src
nox-0:2023.04.22-3.fc39.noarch
nox-0:2023.04.22-3.fc39.src
pepc-0:1.4.25-3.fc39.src
pipx-0:1.2.0-5.fc39.noarch
pipx-0:1.2.0-5.fc39.src
pmbootstrap-0:1.53.0-3.fc39.src
pytest-0:7.3.2-4.fc39.src
python-knack-1:0.11.0-1.fc39.src
python3-azure-cli-core-0:2.51.0-1.fc39.noarch
python3-barman-0:3.7.0-1.fc39.noarch
python3-colcon-argcomplete-0:0.3.3-16.fc39.noarch
python3-knack-1:0.11.0-1.fc39.noarch
python3-lib389-0:2.4.3-1.fc39.noarch
python3-pepc-0:1.4.25-3.fc39.noarch
python3-rpkg-0:1.66-10.fc39.noarch
rpkg-0:1.66-10.fc39.src
rpmdevtools-0:9.6-4.fc39.noarch
rpmspectool-0:1.99.7-12.fc39.noarch
virt-manager-common-0:4.1.0-3.fc39.noarch
Thanks,
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3 weeks, 1 day
%pyproject_save_files license handlers
by Maxwell G
Hi Pythonistas,
%pyproject_save_files automatically handles marking license files
with %license when a build backend installs them into a package's
dist-info directory and the License-File header is specified in the
METADATA file. Currently, only setuptools and hatchling meet this
criteria. Notably, poetry and flit do not support this. They will
install license texts into the dist-info directory, but they do not add
the License-File metadata. The License-File tag is not standardized, and
discussion on PEP 639 which defines this standard has stalled. I believe
relying on this feature is a problem, as if a project changes build
systems or some other config and a packager doesn't realize, suddenly
the license file won't be marked with %license or even worse, not
installed at all. Since the pyproject macros read the build backend from
pyproject.toml without packagers having to manually specify anything
(which is generally great!), this situation seems likely to occur.
Until these issues are resolved, I propose banning this in Fedora and
requiring packagers to manually mark files with %license or at least
adding a large warning to the Packaging Guidelines. It can be similar to
the `'*' +auto` flags which are used by pyp2spec for automatic PyPI
builds in Copr but not allowed in Fedora proper.
What do y'all think? Am I missing something?
--
Best,
Maxwell G (@gotmax23)
Pronouns: He/They
4 weeks, 1 day
Intent to orphan several python packages
by Mukundan Ragavan
I am going to orphan the following packages unless someone wants to pick
them up. I do not have time to maintain them anymore since the
dependencies have become more and more complex with each release.Several
of these packages do not have dependencies packaged in Fedora.
spyder (docstring-to-markdown)
python-rope (pytoolconfig)
python3-lsp-server (yapf >=0.33)
python-lsp-black
python-lsp-server
python-lsp-jsonrpc
python-pyls-spyder
python-qdarkstyle
Let me know if you want to pick up any of these. Thanks.
Mukundan.
1 month, 1 week
Rust bindings for Python (pyo3 versions <0.19, cpython) broken with
Python 3.12
by Fabio Valentini
Hello Pythonistas and Rustaceans,
TL;DR: Only PyO3 v0.19.2 (and later) will ever properly support Python
3.12. Port your Python projects to v0.19 **NOW**.
Older versions of PyO3 (especially pyo3 v0.15, v0.16, v0.17, and
v0.18) are *not* compatible with Python 3.12 due to some ABI changes
in unicode strings and behavioural changes wrt/ "immortal" objects.
This also affects all current versions of the "cpython" Rust bindings,
with no timeline for Python 3.12 support.
As far as I can tell, extensions that use pyo3 < v0.19 or the
"cpython" bindings can (and likely will) not work as expected on
Python 3.12 if they use the affected APIs (either by producing garbage
data in strings that are passed over the FFI boundary, or by
crashing).
There are applications in Fedora that still rely on *ancient* versions
of PyO3, potentially affected by this:
- cpython: mercurial
- pyo3 v0.15: fapolicy-analyzer, python-bcrypt, python-cryptography
- pyo3 v0.16: python-y-py
- pyo3 v0.17: unused compat packages, will be retired
- pyo3 v0.18: matrix-synapse
I *stongly* recommend to move all of these packages to pyo3 v0.19 in
Rawhide as soon as possible. I will try to submit pull requests with
the required changes for affected packages (except mercurial, since
there's no version of the "cpython" crate that supports Python 3.12 in
sight).
There's already a few packages that depend on pyo3 v0.19, which I will
rebuild in rawhide for pyo3 v0.19.2, which has much better support for
Python 3.12 than v0.19.0 and v0.19.1 (breezy, python-rpds-py, orjson)
unless there are any objections.
As soon as no packages depend on the compat packages for old versions
of pyo3 any longer, I will retire them from Rawhide (and F39,
depending on the timing), since they will never work with Python 3.12
and nothing should use them.
I've added <package>-maintainers(a)fedoraproject.org for all these
packages to the CC of this message.
Fabio
Rust SIG / PyO3 maintainer in Fedora
1 month, 3 weeks
