python-devel July 2024

python-devel@lists.fedoraproject.org

8 participants
4 discussions

The RPM pyproject Declarative Buildsystem is available in Rawhide
by Miro Hrončok 13 Aug '24

13 Aug '24

Hello Pythonistas, pyproject-rpm-macros 1.14.0 landed in Fedora Rawhide and ELN. It defines a provisional Declarative Buildsystem for RPM 4.20+. It allows you to write Python specfiles like this: --------------------------------- Name: python-pello Version: 1.0.4 Release: %autorelease Summary: Example Python library License: MIT-0 URL: https://github.com/fedora-python/Pello Source: %{url}/archive/v%{version}/Pello-%{version}.tar.gz BuildSystem: pyproject BuildOption(install): -l pello BuildArch: noarch %description ... %package -n python3-pello Summary: %{summary} %description -n python3-pello ... %files -n python3-pello -f %{pyproject_files} %doc README.md %{_bindir}/pello_greeting --------------------------------- It will fill-in %prep, %generate_buildrequires, %build, %install, and %check sections for you. Yet you can configure/extend/override the sections if needed. Read about all the possibilities at https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/READ… in the *Provisional: Declarative Buildsystem (RPM 4.20+)* section. This is still *provisional* and the API might change in the future. Beware that RPM in Fedora 39/40 and EPELs does not understand this and RPM < 4.20 will not parse such spec files, so this is inconvenient to use unless you run Rawhide -- fedpkg prep, rpmbuild -bs, spectool -g, rpmdev-bumpspec won't work properly... If you don't use Rawhide, you can build a SRPM like this: mock -r fedora-rawhide-x86_64 --enablerepo=local --resultdir=./ --buildsrpm --spec python-pello.spec --source Pello-1.0.4.tar.gz Or use fedpkg with --srpm-mock. However, even some infra tools that don't run on Rawhide will likely fail with a package like this (e.g. Copr or Zuul). Use this at your own risk. Koji builds SRPMs for Rawhide on Rawhide, so it works there. Please experiment with this and report back how does it work for you. Happy packaging. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

1 1

Default BuildOption(install) for the RPM pyproject declarative buildsystem
by Miro Hrončok 13 Aug '24

13 Aug '24

Hello. I am working on the RPM pyproject declarative buildsystem. t;dr it turns this: BuildSystem: pyproject into this: %prep %autosetup -p1 -C %generate_buildrequires %pyproject_buildrequires %build %pyproject_wheel %install %pyproject_install %pyproject_save_files ... %check %pyproject_check_import It allows to override options to sections with BuildOption. For detailed documentation, see https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/455 (it has README changes in it). --------------------------------- What should be the default for BuildOption(install)? That is, what should be passed to %pyproject_save_files if the packager does not override it? 1. The safe+hard default: nothing ================================= The %pyproject_save_files macro currently has no default. It requires at least one argument. This is to avoid accidentally packaging something we don't want. Explicit is better than implicit. For this reason, users of the pyproject declarative buildsystem would be required to always set BuildOption(install) explicitly. Why I don't like this option: The declarative buildsystem was invented to make spec files simpler. Making BuildOption(install) mandatory defeats the purpose. 2. The easy+dangerous default: '*' ================================== When we pass '*' to %pyproject_save_files by default, we ensure all packages work without BuildOption(install). This is the easy way. Everything is automagic, no boilerplate necessary. Passing '*' to %pyproject_save_files is forbidden by the Fedora packaging guidelines because it is dangerous. If upstream removes a Python module or (perhaps accidentally) adds a new one that conflicts with other packages, the Fedora packager should notice. Why I don't like this option: The default is forbidden in Fedora and hence it is only useful elsewhere (e.g. Copr). Defaults should encourage the desired pattern, defaults should not be forbidden. Packagers will use the default and the rule will be ignored as not practical. 3. Guess the module name: python-foo -> foo =========================================== When the package is named somehow, we like the Python modules to be named identical-ish. We can create a transformation of %{name} and make that the default. Something like this: 1. Strip python- prefix if found. 2. Strip everything after a dot (including the dot) if found. 3. Convert dashes, dots etc. to underscores. Some nice examples: python-requests -> requests python-zope.interface -> zope python-flit-core -> flit_core tomcli -> tomcli Examples that would need manual BuildOption(install): python-zope-interface -> zope_interface (we need zope) python-djangorestframework -> djangorestframework (we need rest_framework) pytest -> pytest (we need pytest _pytest py) This would produce a reasonable default that is easy and safe for sane packages but it is not dangerous for the weird ones. Option 3a) is to do this in the pyproject declarative buildsytsem macros implementation. Explicit callers of %pyproject_save_files would not be able to use this, which only has downsides. Option 3b) is to make this the behavior of %pyproject_save_files when it has no arguments. If additional module globs are necessary, all module globs need to be passed explicitly. Option 3c) is to make this the behavior of `%pyproject_save_files -n` and make -n the default BuildOption(install). Users of %pyproject_save_files could combine -n with explicit module glob list (e.g. `%pyproject_save_files -n _pytest py` for pytest). Why I don't like this: Its' heuristics. It smells like guesswork. I prefer things explicit. 4. Default to %{pypi_name} ========================== Similarly to option 3, we prefer the PyPI name and the module name to match. Hence, we could default to %{pypi_name} or %{srcname} like %{pypi_source} does. There would still need to be some transformations applied, because %{pypi_name} can contain dashes and dots, etc... Why I don't like this: %{pypi_name} is not a cardinal part of a package. It's not part of the Python packaging guidelines and does not have a clearly defined semantics (is it the project name or the name part of the source tarball?). It encourages packagers to define the macro and use it everywhere in the spec, making it harder to read. Moreover, we need to apply text transformations to it anyway, hence we might as well do them on %{name} directly (which does not have clear semantics either, but is always there). --------------------------------- If I had to pick, I'd go with 3c. IMHO it is the most sane option. What are your thoughts? Do you see other options? -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

4 7

New to the list, keen to contribute!
by Igor Jagec 12 Jul '24

12 Jul '24

Hey all, I'm Igor, a long-time Linux and middleware admin (Red Hat/Fedora user since 2001!). I'm currently diving into Python and figuring it all out – always been a big fan of learning by doing, so I thought this would be a great place to get stuck in. Hoping to find my place within the Fedora community and contribute properly. Any pointers on where I could start would be much appreciated. Cheers, Igor

2 1

How to pass configuration options to %pyproject_wheel
by Antonio T. sagitter 09 Jul '24

09 Jul '24

Hi all. How i can pass configuration options to %pyproject_wheel? For example, i wish to change this line %py3_build -- --enable-qcas --executable="%{__python3} -s" with %pyproject_wheel ... but i don't know how to include "--enable-qcas" -- --- Antonio Trande Fedora Project https://fedoraproject.org/wiki/User:Sagitter mailto: sagitter(a)fedoraproject.org GPG key: 0x40FDA7B70789A9CD GPG keys server: https://keys.openpgp.org/

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel July 2024