python-devel November 2024

python-devel@lists.fedoraproject.org

6 participants
6 discussions

Retire Python 3.8 from Fedora 42+?
by Miro Hrončok 10 Dec '24

10 Dec '24

Hey Pythonistas, - Python 3.8 reached upstream End of Life 2024-10-07. - RHEL 8 Python 3.8 Stream has been retired since May 2023. - Debian buster had Python 3.7, bullseye has 3.9. - Ubuntu 20.04 LTS (Focal Fossa) has Python 3.8. - Standard support ends April 2025. Fedora 42 release date is April 2025. Hence I think we should retire Python 3.8 from Fedora 42+ Any other use case for Python 3.8 I missed? -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

2 3

How to package Python bindings for Tree-sitter parsers?
by Peter Oliver 26 Nov '24

26 Nov '24

TL;DR: Should Rust bindings for Tree-sitter parsers be packaged independently (using the usual Python packaging process), or should they be a subpackage of the main Tree-sitter parser package (effectively giving us Python bindings for free)? Do we even want Python bindings for Tree-sitter parsers in the first place? Here’s the long version. Tree-sitter is a library for writing parsers for source code, for use in, for example, syntax highlighters and text editors. Nearly 500 different parsers are available separately (https://github.com/tree-sitter/tree-sitter/wiki/List-of-parsers) However, we only have one of them packaged for Fedora so far. Spec files for Tree-sitter parsers will all be very similar to each other, and could probably be generated by simple-minded RPM macros (a draft of which are at https://src.fedoraproject.org/rpms/tree-sitter/pull-request/1#request_diff) Official bindings are available for using the parsers from a number of languages, including Python. The Tree-sitter project has tooling to automatically generate these bindings, which are committed to the Git repository of each parser. On release, the bindings are uploaded to the native repository for each language (i.e., pypi.org for Python). This gives us a choice: - We could treat Python bindings for Tree-sitter as any other Python project, with the souce fetched from pypi.org. If someone wanted them, they would need to package them in the usual Python way. - We could package Python bindings for Tree-sitter as a subpackage of the package that builds the parser as a C library, with the source fetched from github.com. We would have Python bindings for every Tree-sitter parser packaged for Fedora. The Tree-sitter-specific RPM macros used in these packages may need tweaking in future to keep up with any changes to the Python packaging guidelines. Which sounds preferable? By the way, I have asked this question on the packaging list (https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject .org/thread/X3B2MYPPSWBGWRFD7K62NNLIMIL3O56F/), but it didn’t generate much discussion. I’ve also asked the equivalent question to the Rust SIG. -- Peter Oliver

2 1

pyproject-rpm-macros 1.15/1.16: %pyproject_buildrequires -p and -g
by Miro Hrončok 26 Nov '24

26 Nov '24

Hey Pythonistas, %pyproject_buildrequires has gained 2 new flags: -p and -g -p reads runtime dependencies (and extras given via -x or read from tox configuration) directly from the pyproject.toml [project] table. This is useful for backends that do not implement the optional prepare_metadata_for_build_wheel PEP 517 hook. Ideally, this should replace all usages of the provisional -w flag (and we are filing Pull Requests for such cases). This was added to pyproject-rpm-macros 1.15 by Karolina Surma. -g generates BuildRequires specified via given dependency group(s) from the pyproject.toml [dependency-groups] table. See PEP 735: https://peps.python.org/pep-0735/ If you use %pyproject_buildrequires with tox (-t/-e) and tox is configured to use a dependency group, this will work as well with tox 4.23+. This was added to pyproject-rpm-macros 1.16 by me. The new 1.16 version of pyproject-rpm-macros is available in all Fedoras and is on its way to c10s and c9s. tox 4.23 is currently available in Rawhide + updates-testing on stable Fedoras. I will also update it in EPEL 10 soon (it waits for pyproject-rpm-macros 1.16 in c10s). EPEL 9 is stuck with tox 3 for the time being (likely forever). Happy packaging, -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

1 1

Re: Should I join python-packagers?
by Miro Hrončok 12 Nov '24

12 Nov '24

On 04. 11. 24 21:25, Blaise Pabon via python-packagers-sig wrote: > I think I would like to join python packagers... unless the group is only > concerned with packaging the cpython language for Fedora. Hello Blaise, first of all, python-packagers-sig(a)lists.fedoraproject.org is not for communication, it is for Bugzilla emails. See https://fedoraproject.org/wiki/SIGs/Python#Communicate The python-packagers-sig group is not only concerned with packaging the cpython interpreter. It is described in https://fedoraproject.org/wiki/SIGs/Python#Python_SIG_FAS_group > According to https://accounts.fedoraproject.org/group/python-packagers-sig/ > <https://accounts.fedoraproject.org/group/python-packagers-sig/> I should > contact one of the group sponsors, but I don't know how they will respond to > some random guy who is not yet even a proven packager. Being provenpackager is not a prerequisite for joining the group, it's the other way around really, this group is like "provenpackagers for packages co-maintained by the group". Demonstrating a deeper understanding of Python packaging in Fedora is necessary. Why do you want to join in the first place? -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

1 0

%pyproject_save_files for packages without Python modules
by Miro Hrončok 11 Nov '24

11 Nov '24

Hello Pythonistas. I came across a couple packages that only install .dist-info in %python3_sitelib/arch, or an additional .pth file. E.g. it's a Python-packaged command line tool that installs /usr/bin/foo + .dist-info only (e.g. badchars, ddiskit, fuzza, isrcsubmit, ksc, pwncat, python-vevents, urlbuster, snallygaster). Or it installs a .pth file + dist-info.only (e.g. python-coverage_pth). Currently, there is only one way to use %pyproject_save_files with them: %pyproject_save_files '*' THis works because a special case exists in %pyproject_save_files to support automated packaging e.g. in Copr. When the list of module globs contains '*', we assume no modules at all are OK. However, we do not allow '*' in official Fedora packages. %pyproject_save_files currently requires at least one argument. So there is no way to call it with no globs. Currently, such packages need to manually list %{python3_sitelib}/xxx-%{version}.dist-info in %files. And they don't benefit from automatic %license discovery. I want to change that, but I want to consult the API ideas: 1. Allow %pyproject_save_files without arguments ================================================ %pyproject_install %pyproject_save_files Simple, easy. Calling %pyproject_save_files without arguments will work and it will only save the .dist-info for %{pyproject_files}. (This will allow to use the pyproject RPM declarative BuildSystem without BuildOption(install) as well.) Are there any downsides? Even if packages forget to add arguments to %pyproject_save_files, this will work: %install %pyproject_install %pyproject_save_files %files -n python3-foo -f %{pyproject_files} %{python3_sitelib}/foo/ My only worry now is that the "default" behavior of %pyproject_save_files exists only to accommodate a very niche need. 2. Empty string argument ======================== %pyproject_install %pyproject_save_files '' Empty argument means no modules. I don't like this, it's hard to read, hard to explain. 3. Another +argument ==================== %pyproject_install %pyproject_save_files +nomodules We already have +auto, so this would be another +thing. I don't like this much, but more than 2. 4. Another short option ======================= %pyproject_install %pyproject_save_files -M (The character choice is arbitrary.) We already have -l/-L. This would be another such option. 5. Do not require %pyproject_save_files in that case ==================================================== %pyproject_install This would populate %{pyproject_files} with the .dist-info only. Subsequent %pyproject_save_files calls would override/expand it. However, there are challenges: what happens if there are multiple wheels installed this way? etc. ----- I'd probably go with option 1. But perhaps there's something else I have not figured out. Thoughts? -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

3 2

How to pass arbritary options in SPEC file for python build
by Gerald B. Cox 06 Nov '24

06 Nov '24

Posted originally here: https://discussion.fedoraproject.org/t/how-to-pass-arbritary-options-in-spe… I’m currently refactoring the picard spec file to conform to the new python build guidelines (used pyprojectize, thanks!), everything fine there so I thought I’d add --disable-autoupdate so as to remove the new update option at runtime. Picard allows for this by using --disable-update. When I try: %pyproject_wheel -C–disable-autoupdate=None It build fine, but doesn’t work. I’ve asked the good folks at the Picard forum and here is the response: I tried getting options to pass with python -m build, but without success. Picard is using the setuptools backend, and it looks like passing arbitrary options is currently not working there. See the discussion at Setuptools does not pass config_settings through backend · Issue #2491 · pypa/setuptools · GitHub . I would have expected something like python -m build --wheel -C--disable-autoupdate or maybe python -m build --wheel -C--disable-autoupdate=True should work, but it doesn’t for now, as the parameters are not passed on. One workaround seems to be to add a custom build backend that overrides the relevant parts to handle the customer build parameters as it was done for example in Add custom build backend to support build args by tobiasah · Pull Request #328 · capnproto/pycapnp · GitHub We could also maybe check for specific environment variables or such. But ideally the issue gets solved in setuptools itself. Am I missing some functionality in the Fedora buildtools or is this just not possible. Thanks for any insights.

3 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel November 2024