python-devel September 2024

python-devel@lists.fedoraproject.org

5 participants
3 discussions

Loudly deprecating setup.py-based macros %py3_build %py3_install
by Miro Hrončok 30 Sep '24

30 Sep '24

Hello Pythonistas, setuptools has deprecated executing setup.py (e.g. setup.py build/install) long time ago. It is only a matter of time when it won't be possible to use %py3_build, %py3_install, and %py3_build_wheel. Recently, the removal of setup.py test broke almost 200 packages. In Fedora, the "old" macros (%py3_build, %py3_install) are: 1. deprecated: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_deprecat… 2. yet allowed: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/ Considering the fact that 1.6k Python packages use the macros (while 2k use the %pyproject_ ones), we are in for a lot of trouble when setuptools removes the support for setup.py build/install. To prevent such disaster I'd like to: - emit loud deprecation warnings from the macros, possibly with 10 sec sleep - officially disallow https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/ A proof of concept for the deprecation is https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/180 Later, I'd like to experiment with https://github.com/packit/specfile to write a minimal automatic convertor from the old macros to the new. It won't be perfect and likely won't be able to ditch any manually listed BuildRequires at first, but at least it might allow us to mass update spec files while keeping them buildable. Let me know what you think about this. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok

3 5

%pyproject_buildrequires -r/-x: Attempt to read runtime dependencies from pyproject.toml?
by Karolina Surma 24 Sep '24

24 Sep '24

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

4 4

Django packaging options for alternate stacks - advice needed
by Michel Lind 05 Sep '24

05 Sep '24

Hi all, Since we need the Django stack in EPEL for running the mailing list infra, a few months ago the EPEL Steering Committee discussed a plan to package Django LTS versions in EPEL, with RPM-based Provides/Conflicts to allow swapping between different Django stacks https://pagure.io/epel/issue/271 (Documentation still forthcoming, and it's probably a good idea to formalize the Provides/Conflicts convention first) Carl has since pointed out that there are situations where python-django (the old package, which we now intend to track the latest Django release) and python-djangoX.Y (the LTS package, the first and currently only available is python-django4.2) happen to be the same version, and that it could be confusing* * I personally think it's fine, as the two are interchangeable anyway - * and if a dependency is not compatible with python-django, then users * can swap to the LTS package and keep everything * ... but this can be better documented if we continue down this route, * e.g. with a README.Fedora pointing to the website docs The alternative Carl suggested is to package each python-djangoX.Y we need separately - and that way avoid ever having two package having the same version, similar to how the multiple Python versions are packaged. We thought the SIG might want to chime in on this (might as well sort it out before I start writing documentation anyway) - any pros/cons we have not thought up, and any recommendation about which is better overall? Thanks, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel September 2024