python-devel June 2023

python-devel@lists.fedoraproject.org

9 participants
10 discussions

[HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
by Tomas Hrnciar 05 Jul '23

05 Jul '23

Hello, in order to deliver Python 3.12, we are running a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.12 We anticipate starting this rebuild sometime this week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f39-python $ koji wait-repo f39-python --build <nvr> Note that it will take a while before all the essential packages are rebuilt, so don't expect all your dependencies to be available right away. Please, don't attempt to build your package in the side tag before we do. When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me (thrnciar) or Miro (mhroncok) if you need to talk to us. Builds: https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f39-python&order=… Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks. Let us know if you have any questions.

5 14

Circular import issue in F37
by Sandro 25 Jun '23

25 Jun '23

Hi again, I'm trying to understand why I'm getting a circular import error running tests only in F37 [1]. It's an easy fix adding an empty __init__.py in %prep, but why are F38 and rawhide buildroots happy not having that file, while F37 complaints? The versions of the involved packages only differ in minor / patch versions between F37 and F38, if at all. With python-setuptools-wheel being the only package with a different major version. python3-devel 3.11.3-2.fc37 3.11.3-2.fc38 python3-pytest 7.1.3-2.fc37 7.2.2-1.fc38 pyproject-rpm-macros 1.8.0-1.fc37 1.8.0-1.fc38 python-rpm-macros 3.11-5.fc37 3.11-10.fc38 python-pip-wheel 22.2.2-3.fc37 22.3.1-2.fc38 python-setuptools-wheel 62.6.0-3.fc37 65.5.1-2.fc38 [1] https://copr.fedorainfracloud.org/coprs/gui1ty/neuro-sig/build/6002232/ Cheers, -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee

2 4

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
by Miro Hrončok 18 Jun '23

18 Jun '23

On 18. 06. 23 15:17, Barry Scott wrote: > > >> On 17 Jun 2023, at 10:50, Miro Hrončok <mhroncok(a)redhat.com> wrote: >> >> Please avoid further rawhide builds of them until the side tag is merged. > > I have been fixing pycxx and pysvn for python 3.12. > I have released new pycxx and pysvn upstream that fix the 3.12 issues. > > But I did not see your message about not building in rawhide, sorry. > > python-pycxx was buildt in rawhide. > I have not built pysvn in rawhide. > > For both packages I have pushed updates to sources and spec file that are needed > for 3.12 support. > > For pycxx need to have conditional access to _Py_PackageContext and replace use > of distutils. > > For pysvn fix a SEGV when the process exits. > I'v attempted to rebuild python-pycxx: Traceback (most recent call last): File "/builddir/build/BUILD/pycxx-7.1.8/setup.py", line 3, in <module> from distutils.command.install import install ModuleNotFoundError: No module named 'distutils' The distutils module eas removed from the Python standard library. You should be able to fix this by BuildRequiring python3-setuptools. Cannot build pysvn yet, as it is blocked by the above. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
by Miro Hrončok 16 Jun '23

16 Jun '23

On 16. 06. 23 12:07, Nikita Popov wrote: > We have a conflicting python-lit build sitting in another side tag -- we'll > discard that one and rebuild once your side tag is merged. If it's already built and ready to be shipped, do it. Our side tag will last for ~1 week at least. Happy to bump python-lit once again to make your side tag work unblocked. Just let us know. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
by Miro Hrončok 16 Jun '23

16 Jun '23

On 16. 06. 23 9:57, Bastien Nocera wrote: > > > On Fri, 16 Jun 2023 at 09:48, Miro Hrončok <mhroncok(a)redhat.com > <mailto:mhroncok@redhat.com>> wrote: > > On 16. 06. 23 9:41, Bastien Nocera wrote: > > Scolding people that haven't seen your original message for limitations > in the > > build system isn't nice. > > Apologies for not being nice enough. However, we need to notify the folks who > do that and ask them to stop, because as you say, the system is not perfect. > > If you have specific suggestions, please speak up. > > > Yes, tell folks that they might have missed an email instead of sending a > scolding " Please, don't do that." Thanks for the suggestion. I honestly had no idea that "please, don't do that" could be considered unfriendly, but I hope that's language/cultural barrier (rather than me being a sociopath). I've adjusted my wording in the followup emails. > > I fixed my missing the devel-announce email by subscribing to the list > (though > > this should probably be implemented somewhere in the accounts system) > but I'm > > afraid I cannot do anything about the build system not allowing for > specific > > blocking of builds in circumstances such as yours. > > I kindly ask you not to submit rawhide builds of packages that have been > already built in our side tag, until the side tag is merged. If you cannot do > that, I kindly ask you not to build any packages until the side tag is merged. > Unfortunately, asking people is the only thing I am able to do. > > > I'm talking about limitations in the build system that don't allow you to > automatically do what you're trying to get *people* to do instead. > > People are fallible, and filing an RFE for the build system would go some way > to shifting the burden to a computer. This has actually been discussed on this list several times already, but Fabio was kind enough to file that RFE today: https://pagure.io/koji/issue/3847 That said, most of Fedora's RFEs to Koji that would make things easier for packagers seem to linger, presumably due to capacity reasons. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
by Miro Hrončok 16 Jun '23

16 Jun '23

On 16. 06. 23 9:41, Bastien Nocera wrote: > Scolding people that haven't seen your original message for limitations in the > build system isn't nice. Apologies for not being nice enough. However, we need to notify the folks who do that and ask them to stop, because as you say, the system is not perfect. If you have specific suggestions, please speak up. > I fixed my missing the devel-announce email by subscribing to the list (though > this should probably be implemented somewhere in the accounts system) but I'm > afraid I cannot do anything about the build system not allowing for specific > blocking of builds in circumstances such as yours. I kindly ask you not to submit rawhide builds of packages that have been already built in our side tag, until the side tag is merged. If you cannot do that, I kindly ask you not to build any packages until the side tag is merged. Unfortunately, asking people is the only thing I am able to do. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

nest: python package still setup.py; also needs to be built for MPI
by Ankur Sinha 15 Jun '23

15 Jun '23

Hi folks, I'm in the process of updating the nest package to the latest release. It uses cmake as its build system, but then the cmake calls `python setup.py install` and so on to install the Python API. So, we strip that bit out and call these commands ourselves in the right places in the spec[1,2,3]. As you'll also see from the spec, nest supports MPI, so we build it 3 times: - without MPI - once with openmpi - once with mpich For the MPI builds, we need to pass the `--install-lib=$MPI_SITEARCH` option to `python setup.py install` to get it to install the bits in the right MPI related locations. I've noticed that using this system now gives us deprecation warnings during the build since calling `setup.py ...` explicitly is deprecated. However, I can't figure out how I would replicate the build using the `pyproject` macros. I guess `pyproject_wheel` usage is straightforward (?), but how do I get `pyproject_install` to install in the $MPI_SITEARCH locations, and then how do I get `pyproject_save_files` to store the files in three different lists that I can use in the different `%files` sections? [1] https://src.fedoraproject.org/rpms/nest/blob/rawhide/f/0001-Disable-python-… [2] https://src.fedoraproject.org/rpms/nest/blob/rawhide/f/nest.spec#_342 [3] https://src.fedoraproject.org/rpms/nest/blob/rawhide/f/nest.spec#_424 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London

3 10

Question regarding setuptools automatic discovery (pyproject.toml)
by Sandro 05 Jun '23

05 Jun '23

Hi, I ran into a build failure for a Python package that dropped setup.py in the latest update and uses pyproject.toml for metadata and setuptools. The build failed due to 'error: Installed (but unpackaged) file(s) found' [1]. However, all the erroneously installed modules should be excluded by default, if I understand the setuptools automatic discovery documentation [2] correctly. They are listed in 'FlatLayoutPackageFinder.DEFAULT_EXCLUDE'. In this case 'docs', 'scripts' and 'test'. Since this is still beta when using pyproject.toml, I was wondering if someone else has come across this misbehavior. Or, maybe, it's something I failed to spot in pyproject.toml, that's causing it. I can make it work by adding a 'include = ["palettable"]' in the tool.setuptools.packages.find table [3]. But I'd like a second opinion before submitting a PR upstream. [1] https://kojipkgs.fedoraproject.org//work/tasks/5770/101775770/build.log [2] https://setuptools.pypa.io/en/latest/userguide/package_discovery.html#flat-… [3] https://copr.fedorainfracloud.org/coprs/gui1ty/neuro-sig/build/6000976/ Cheers, -- Sandro FAS: gui1ty IRC: Penguinpee Elsewhere: [Pp]enguinpee

3 4

python macros inconsistency between Fedora and EPEL9
by Mattia Verga 03 Jun '23

03 Jun '23

In the test section of libindi package I use this to run tests: %ctest --test-dir %_vpath_builddir/test This translates in Fedora as: + /usr/bin/ctest --test-dir redhat-linux-build --output-on-failure --force-new-ctest-process -j6 --test-dir redhat-linux-build/test Internal ctest changing into directory: /builddir/build/BUILD/indi-2.0.2/redhat-linux-build/test While on EPEL (at least, in COPR): + /usr/bin/ctest --output-on-failure --force-new-ctest-process -j2 --test-dir redhat-linux-build/test Internal ctest changing into directory: /builddir/build/BUILD/indi-2.0.2/redhat-linux-build/redhat-linux-build/test Failed to change working directory to "/builddir/build/BUILD/indi-2.0.2/redhat-linux-build/redhat-linux-build/test" : No such file or directory I'm not sure against what package I should report this. Python-rpm-macros seems a Fedora package only, I don't see any epel9 build there. And, most important, I don't know if I'm doing something wrong or if is indeed something to report. Can anyone clarify me these two things? Thanks Mattia

2 2

pyproject-rpm-macros 1.9.0: Support for passing config_settings to the build backend
by Miro Hrončok 02 Jun '23

02 Jun '23

Hello Pythonistas, Let me announce the release of pyproject-rpm-macros 1.9.0. The new version is available in Rawhide+ELN Koji and updates are penfing for older Fedora releases. A sync to c9s is in progress but will require a review, so it might take longer. The new version has the following changes compared to 1.8.0: Allow passing config_settings to the build backend ================================================== Contributed by Maxwell G (@gotmax23), thank you! From the README: ------------------------------------------------------------------------------- The %pyproject_buildrequires and %pyproject_wheel macros accept a -C flag to pass configuration settings [1] to the build backend. Options take the form of -C KEY, -C KEY=VALUE, or -C--option-with-dashes. Pass -C multiple times to specify multiple options. This option is equivalent to pip's --config-settings flag. These are passed on to PEP 517 hooks' config_settings argument as a Python dictionary. The %pyproject_buildrequires macro passes these options to the get_requires_for_build_wheel and prepare_metadata_for_build_wheel hooks. Passing -C to %pyproject_buildrequires is incompatible with -N which does not call these hooks at all. The %pyproject_wheel macro passes these options to the build_wheel hook. Consult the project's upstream documentation and/or the corresponding build backend's documentation for more information. Note that some projects don't use config settings at all and other projects may only accept config settings for one of the two steps. Note that the current implementation of the macros uses pip to build wheels. On some systems (notably on RHEL 9 with Python 3.9), pip is too old to understand --config-settings. Using the -C option for %pyproject_wheel (or %pyproject_buildrequires -w) is not supported there and will result to an error like: Usage: /usr/bin/python3 -m pip wheel [options] <requirement specifier> ... ... no such option: --config-settings [1] https://peps.python.org/pep-0517/#config-settings ------------------------------------------------------------------------------- Previously, packagers needed to patch for this: https://src.fedoraproject.org/rpms/python-scikit-misc/c/3dda47b4b7 On Python older than 3.11, use tomli instead of deprecated toml =============================================================== All currently supported Fedora releases have Python 3.11, so this has not a big effect except for EL 9. However, all packages had generated this BuildRequires: (python3dist(toml) if python3-devel < 3.11) This will now be: (python3dist(tomli) if python3-devel < 3.11) Such build requirements in Fedora manifests themselves in the results of dnf repoquery --wahtrequires python3-toml(i). Fix literal % handling in %{pyproject_files} on RPM 4.19 ======================================================== If your package has files with literal % signs in the filenames, it was briefly broken on Fedora Rawhide, because RPM 4.19 now requires 2 % signs to escape them in the filelist (it was 8 in RPM 4.16 and 4.17). This has now been fixed. Unfortunately, to support both RPM 4.19 and older ones, there is a conditional in %pyproject_save_files which checks the Fedora version. If you run old RPM on Fedora 39 or new RPM on older Fedoras and ahve literal % signs in filenames, it will break. I have requested an %rpmversion macro from RPM and it was added upstream. Once propagated to Fedora, the conditional will be replaced. Happy packaging! -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel June 2023