Re: How to pass arbritary options in SPEC file for python build
On 06. 11. 24 2:29, Gerald B. Cox via python-devel wrote: Hi Miro, Thanks for taking the time to respond. I'm probably not doing a very good job explaining this. Perhaps it would help you understand better if you went directly to the ticket where the option was created: https://tickets.metabrainz.org/browse/PICARD-1325 Hope that helps. It seems to be: python setup.py build --disable-autoupdate That should be -C--build-option=--disable-autoupdate, but I have never actually used it this way. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to pass arbritary options in SPEC file for python build
On 05. 11. 24 19:40, Gerald B. Cox via python-devel wrote: so upstream created the option to disable the update dialog via the --disable-autoupdate option What is this option for? Where are you supposed to use it? -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to pass arbritary options in SPEC file for python build
On 05. 11. 24 0:36, Gerald B. Cox via python-devel wrote: Posted originally here: https://discussion.fedoraproject.org/t/how-to-pass-arbritary-options-in-spec-file-for-python-build/135434/ 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. The --disable-autoupdate flag is for what exactly? If this is a flag for setup.py, you can pass it by -C--global-option=--disable-autoupdate. It looks weird, but this is how the setuptools build backend passes arguments to setup.py. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
%pyproject_save_files for packages without Python modules
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
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: A tool to convert Python packages to pyproject RPM macros
On 12. 10. 24 0:32, Adam Williamson wrote: On Fri, 2024-10-11 at 21:29 +0200, Michal Ambroz wrote: Hello Miro, Thank you very much for the tool - I am adding it to toolbox. I actually love the new pyproject macros, but in the past there were some discrepancies between Fedora and EPEL where not everywhere the situation was ready there to switch to pyproject macros. Please have you checked recently how EPEL8-9-10 is doing with the Fedora pyproject macros? Does it make sense to switch over for all current EPELs? EPEL 8 can't use them. EPEL 9+ can. This is mentioned at the top of https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ . On the whole I'd say it makes sense to use pyproject on all other branches and have EPEL 8 use the old guidelines, in most cases. You *probably* don't want to keep an EPEL 8 branch in sync with Rawhide anyway, we're not supposed to do major version bumps and stuff in EPEL. Pretty much what Adam said. Some details: Python 3.6 in RHEL 8 is probably too old to handle the Python code in pyproject-rpm-macros. This could be fixed by changes in that code of it was the only problem (it isn't). pip 9 in RHEL 8 is too old to support pyproject-based builds. pips for newer Python versions in RHEL 8 are more capable. setuptools 39.2 in RHEL 8 is too old to provide the (default) setuptools.build_meta:__legacy__ backend. setuptools for newer Python versions in RHEL 8 are more capable. RPM 4.14 in RHEL 8 is too old to understand %generate_buildrequires. There is a EPEL 8 version of the pyproject-rpm-macros package, but it is severly limited because of this. tl;dr RHEL 8 is very old. it predates the fundamental principles those macros were build on. Python packaging has evolved in the past 6 years almost beyond recognition. RHEL 8 is too old to catch up. We are at a point where we can no longer build Python RPM packages for EPEL 8 and Fedora form the same spec file, unless we fill it with %if conditionals. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
A tool to convert Python packages to pyproject RPM macros
Hello Pythonistas, The old %py3_build and %py3_install macros (201x-era) as documented in [1] use a deprecated feature of setuptools. It is highly recommended to use the current %pyproject macros instead as documented in [2] and [3] sooner than it becomes necessary. To help you convert your packages from the old Python macros to the new, I wrote a tool called pyprojectize [4]. The tool is not yet packaged in Fedora, as I release new alpha releases too often. It is however installable via pip/uv/pipx from PyPI [5]. To use the tool, run `pyprojectize python-foo.spec`. See the README or --help for further options. The program only operates on the spec file itself, and hence has limited knowledge. The resulting spec file is not guaranteed to be buildable and manual verification and completion of the transition is strongly advised. If you encounter problems, please report them to the issue tracker [6] or directly to me. Happy packaging. [1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_201x/ [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ [3]: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/README.md [4]: https://github.com/hroncok/pyprojectize [5]: https://pypi.org/project/pyprojectize/ [6]: https://github.com/hroncok/pyprojectize/issues -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Loudly deprecating setup.py-based macros %py3_build %py3_install
On 27. 09. 24 23:43, Miro Hrončok wrote:
And there are some outright bugs:
-%{python3_sitelib}/ATpy-*.egg-info
+%{python3_sitelib}/ATpy.dist-info
Here the replacement ate the -* part thinking it is -py3.13.
Not sure how to properly differentiate between:
%{python3_sitelib}/ATpy-*.egg-info
%{python3_sitelib}/ATpy-%{version}-*.egg-info
I guess the name part cannot has dashes in it, so I can work with that.
Fixed (in code and the the example specs as well).
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Loudly deprecating setup.py-based macros %py3_build %py3_install
On 27. 09. 24 18:46, Miro Hrončok wrote:
On 24. 09. 24 13:55, Maxwell G wrote:
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.
I think this would be best presented as a tool that maintainers can use to
help them convert their packages to the new macros while still requiring
manual verification. I am against a bot/script sending a bunch of minimally
tested PRs unless we're at a point where deprecation is very imminent and
packagers have not taken action—although at that point, package retirement
might be the better option.
I drafted a proof of concept:
https://github.com/hroncok/pyprojectize/blob/main/pyprojectize.py
The idea is that we can define individual functions that can update certain
aspects of the specfile. Later, we allow users to turn them on/off.
The overall diff is at
https://github.com/hroncok/pyprojectize/commits/specfiles/
https://github.com/hroncok/pyprojectize/compare/e0193a6a..specfiles
There are some obvious things that will probably blow up:
-%{python3_sitearch}/PyMca5-%{version}-py%{python3_version}.egg-info
+%{python3_sitearch}/PyMca5-%{version}.dist-info
Does this need name-canonization to pymca5?
+AUTOBAHN_USE_NVX=false %pyproject_wheel
+AUTOBAHN_USE_NVX=false %pyproject_install
Setting environment variables like that is not going to work, as the macros
expand to several commands.
And there are some outright bugs:
-%{python3_sitelib}/ATpy-*.egg-info
+%{python3_sitelib}/ATpy.dist-info
Here the replacement ate the -* part thinking it is -py3.13.
Not sure how to properly differentiate between:
%{python3_sitelib}/ATpy-*.egg-info
%{python3_sitelib}/ATpy-%{version}-*.egg-info
I guess the name part cannot has dashes in it, so I can work with that.
But generally, it is already pretty good.
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Loudly deprecating setup.py-based macros %py3_build %py3_install
On 24. 09. 24 13:55, Maxwell G wrote: 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. I think this would be best presented as a tool that maintainers can use to help them convert their packages to the new macros while still requiring manual verification. I am against a bot/script sending a bunch of minimally tested PRs unless we're at a point where deprecation is very imminent and packagers have not taken action—although at that point, package retirement might be the better option. I drafted a proof of concept: https://github.com/hroncok/pyprojectize/blob/main/pyprojectize.py The idea is that we can define individual functions that can update certain aspects of the specfile. Later, we allow users to turn them on/off. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Loudly deprecating setup.py-based macros %py3_build %py3_install
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/#_deprecated_macros 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 -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Proposal: Let's update virtualenv in Rawhide (drops Python 3.6 support)
On 26. 08. 24 12:58, Neal Gompa wrote: On Mon, Aug 26, 2024 at 6:11 AM Miro Hrončok wrote: Hello Pythonistas. The virtualenv version in Fedora is currently stuck at 20.21.1 (April 2023). This is because version 20.22+ dropped support for Python 2.7 and 3.6 virtual environments. Now when Python 2.7 was retired via https://fedoraproject.org/wiki/Changes/RetirePython2.7 the only difference is Python 3.6. If we upgrade virtualenv, developers targeting Python 3.6 (e.g. RHEL 8 platform Python) can use `python3.6 -m venv` to create Python 3.6 virtual environments. Developers using tox can follow https://tox.wiki/en/4.18.0/faq.html#testing-end-of-life-python-versions I propose we bite the bullet and update virtualenv to the latest version in Fedora 42+. Why not do it for 41? The reason we didn't do it before was because of Python 2.7, which we dropped now. Because I think kit's too late in the F41 dev cycle to introduce such change and I am willing to keep backporting fixes to old virtualenv in Fedora 41. The reason was both 2.7 and 3.6. And as of now, 2.7 is still in Fedora 41. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Proposal: Let's update virtualenv in Rawhide (drops Python 3.6 support)
Hello Pythonistas. The virtualenv version in Fedora is currently stuck at 20.21.1 (April 2023). This is because version 20.22+ dropped support for Python 2.7 and 3.6 virtual environments. Now when Python 2.7 was retired via https://fedoraproject.org/wiki/Changes/RetirePython2.7 the only difference is Python 3.6. If we upgrade virtualenv, developers targeting Python 3.6 (e.g. RHEL 8 platform Python) can use `python3.6 -m venv` to create Python 3.6 virtual environments. Developers using tox can follow https://tox.wiki/en/4.18.0/faq.html#testing-end-of-life-python-versions I propose we bite the bullet and update virtualenv to the latest version in Fedora 42+. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: setuptools 72 removes setup.py test, your package(s) will break
On 14. 08. 24 18:21, Paul Howarth wrote:
You can use this opportunity to update your package to the current
Python packaging guidelines, see e.g.
https://src.fedoraproject.org/rpms/python-cachetools/pull-request/4
Affected 199 packages by maintainers based on a simple specfile grep
for ^[^-#].+\bsetup\.py\s+test\b
There are probably quite a few packages not caught by this, for example
python-pycryptodomex, which has:
%check
PYTHONPATH=$RPM_BUILD_ROOT%{python3_sitearch}/ %{__python3} %{py_setup} test
$ rg 'setup\} test\b'
python-journal-brief.spec
64:%{__python3} %{py_setup} test
python-pycryptodomex.spec
107:PYTHONPATH=$RPM_BUILD_ROOT%{python3_sitearch}/ %{__python3} %{py_setup} test
There might also be packages using tox with a tox.ini like this one:
https://github.com/pycrypto/pycrypto/blob/master/tox.ini
Yeah, invocations hidden in tox.ini, Makefile, etc. are harder to grep for.
I might end up building everything in copr and grepping the logs for the error
messages.
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
setuptools 72 removes setup.py test, your package(s) will break
ython-wadllib orion python-iptools python-xlib python-zope-testing orphan python-gerritlib transtats-cli osloup PyGreSQL pbrobinson adapt gtts gtts-token pyjokes python-can python-casttube tpm2-pkcs11 pcmooresetools pghmcfcpython-crypto pingou python-binaryornot python-case python-chai python-flask-xml-rpc python-vobject python-xlrd pkubat PyGreSQL plautrba setools pnemadeansible-inventory-grapher python-bracex python-cpuinfo poros ddiskit praiskup PyGreSQL puiterwijk python-cccolutils pwhalenpyjokes pyowm pwunototools qulogicpython-json-minify python-xmp-toolkit radez python-zc-lockfile python-zope-testing rajeeshknambiar python-ofxparse raphgropython-pdfkit rathannlazygal rcritten cepces python-pyasn1 rdieterpython-mwclient rebus python-colorclass python-oletools python-pcodedmp python-roman rhughespycairo setools robert python-oletools python-pcodedmp rstrodepycairo setools sagitter petsc salimmakitty python-lupa python-pytest-runner python-volatile python-zstd sergiomb python-gammu python-xlib sgallagh python-whoosh sharkczpython-sql python-vobject shoracek tpm2-pkcs11 slinabery python-jsonpath-rw solopasha kitty spichugi python-pyasn1 suanandtranstats-cli suraia python-precis_i18n suve python-ssdeep swt2c binwalk tdecacqu python-statsd terjeros hgsvn python-cwcwidth python-httpsig-cffi python-pyte python-tidy tflink python-xunitparser thebeanogamer classification-banner thmpython-sphinxcontrib-trio python-textile python3-lxc thofmann btrfs-sxbackup tomspurpython-simplegeneric trawetsfros trb143 python-pysword troycurtisjr python-ipdb ttorling python-pysocks vascom python-pymediainfo vmojzissepolicy_analysis setools vtrefnypython-pytimeparse ykarel python-os-service-types zaneb python-autopage zawertun kitty zbyszekcalibre zsun ddiskit -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: The -O3 flag leaked into sysconfig CFLAGS, should we keep it?
On 14. 08. 24 11:04, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Aug 14, 2024 at 01:22:19AM +0200, Miro Hrončok wrote:
On 13. 08. 24 21:45, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Aug 06, 2024 at 11:29:01AM +0200, Miro Hrončok wrote:
On 06. 08. 24 1:20, Miro Hrončok wrote:
Hello Pythonistas.
For years, the CFLAGS embedded in Python sysconfig contained -O2 in
Fedora. This was how Python was built and by default, all flags used to
build Python were embedded.
Later, the flag was removed in Fedora 39 via this change:
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags_Reduction
We wanted to remove as many flags as possible, with this motivation:
"""
Python developers will get more upstream-like experience when building
Python extension modules and also closer to building vanilla C programs.
"""
Note that removing -O2 specifically was not the primary motivation, but
the removal was intentional at that time.
Now we build Python 3.13 with -O3 via this change:
https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3
The change proposal said:
"""
Other Python extension modules will remain bulidng as before, e.g. in
RPM packages, they will still be built with -O2...
"""
However, I made a mistake and the -O3 flag leaked into sysconfig CFLAGS.
The good news is this does not seem to affect RPM packages, they are
still being built with -O2, like this:
<$CFLAGS from automatic %set_build_flags>
E.g. ... -fcf-protection -fexceptions -O3 -O2 -flto=auto ...
The latter flag wins.
OTOH users building their own extension modules will get -O3.
This is not what was intended. However, "Python developers will get more
upstream-like experience" is more true now, because upstream Python
builds use -O3:
$ podman run --rm -ti python:3.12 /usr/bin/bash
# python
>>> import sysconfig
>>> sysconfig.get_config_var('CFLAGS')
'-fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall'
So the question is:
Do we keep -O3 for user-built extension modules for speed and
upstream-like experience? (I would update the -O3 change proposal.)
Or do we loose the flag, as currently documented?
Alternatively, do something else entirely (e.g. embed -O2, or other flag...)?
I slept on it and I support keeping the -O3 flag in sysconfig CFLAGS.
The original motivation for Python_Extension_Flags_Reduction was:
"""
Python developers will get more upstream-like experience when building
Python extension modules and also closer to building vanilla C programs.
"""
Keeping -O3 supports "more upstream-like experience".
Getting rid of it supports "closer to building vanilla C programs".
When choosing from the two, I prefer the first one.
Every time somebody pip installs something without a wheel, or even builds
their own extension module code, on CI etc. they would benefit from the
added speed. If we want Fedora to succeed on the CI field, we should be
competitive.
I think the argument about pip is important: with -O3, the users will
get a "reasonable default". Local pip installs intended for computations
are certainly better with '-O2' or '-O3' rather than the compiler default
of -O0.
But then the setup becomes inconsistent. The flags are:
$ python -c "import sysconfig; print(sysconfig.get_config_var('CFLAGS'))"
-fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG
-fcf-protection -fexceptions -fcf-protection -fexceptions -fcf-protection
-fexceptions
-O3
I'd argue that the goal is to have flags that provide a reasonable
efficient default that integrates well with the cpython code provided
by the distribution,
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
should be included too. (Those flags allow whole-system profiling of
the system, and this works best if all of the system has frame pointers,
so the extensions should have them too.)
I'd argue that whoever wants to profile their system using frame pointers is
also capable of setting the flags for the extension modules their build
themselves.
Let me restate my argument.
I think that there are two possibilities that make sense:
in one, the flags that are exposed are the minimum that is required for
ABI compatibility with the distro build.
In the other, we additionally provide flags that give the most commonly
useful and reasonable defaults.
In the first case, the user has a very clear state, but they have to
include additional flags to get "reasonable behaviour", e.g. efficiency.
In the second case, things work nicely out-of-the-box, but custom and
minimalistic builds require an additional step. I don't think it makes
sense to mix the two, i.e. provide _some_ flags but not all flags for
the common scenario.
Benchmarking with frame pointers is a goal for
Re: The -O3 flag leaked into sysconfig CFLAGS, should we keep it?
On 13. 08. 24 21:45, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Aug 06, 2024 at 11:29:01AM +0200, Miro Hrončok wrote:
On 06. 08. 24 1:20, Miro Hrončok wrote:
Hello Pythonistas.
For years, the CFLAGS embedded in Python sysconfig contained -O2 in
Fedora. This was how Python was built and by default, all flags used to
build Python were embedded.
Later, the flag was removed in Fedora 39 via this change:
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags_Reduction
We wanted to remove as many flags as possible, with this motivation:
"""
Python developers will get more upstream-like experience when building
Python extension modules and also closer to building vanilla C programs.
"""
Note that removing -O2 specifically was not the primary motivation, but
the removal was intentional at that time.
Now we build Python 3.13 with -O3 via this change:
https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3
The change proposal said:
"""
Other Python extension modules will remain bulidng as before, e.g. in
RPM packages, they will still be built with -O2...
"""
However, I made a mistake and the -O3 flag leaked into sysconfig CFLAGS.
The good news is this does not seem to affect RPM packages, they are
still being built with -O2, like this:
<$CFLAGS from automatic %set_build_flags>
E.g. ... -fcf-protection -fexceptions -O3 -O2 -flto=auto ...
The latter flag wins.
OTOH users building their own extension modules will get -O3.
This is not what was intended. However, "Python developers will get more
upstream-like experience" is more true now, because upstream Python
builds use -O3:
$ podman run --rm -ti python:3.12 /usr/bin/bash
# python
>>> import sysconfig
>>> sysconfig.get_config_var('CFLAGS')
'-fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall'
So the question is:
Do we keep -O3 for user-built extension modules for speed and
upstream-like experience? (I would update the -O3 change proposal.)
Or do we loose the flag, as currently documented?
Alternatively, do something else entirely (e.g. embed -O2, or other flag...)?
I slept on it and I support keeping the -O3 flag in sysconfig CFLAGS.
The original motivation for Python_Extension_Flags_Reduction was:
"""
Python developers will get more upstream-like experience when building
Python extension modules and also closer to building vanilla C programs.
"""
Keeping -O3 supports "more upstream-like experience".
Getting rid of it supports "closer to building vanilla C programs".
When choosing from the two, I prefer the first one.
Every time somebody pip installs something without a wheel, or even builds
their own extension module code, on CI etc. they would benefit from the
added speed. If we want Fedora to succeed on the CI field, we should be
competitive.
I think the argument about pip is important: with -O3, the users will
get a "reasonable default". Local pip installs intended for computations
are certainly better with '-O2' or '-O3' rather than the compiler default
of -O0.
But then the setup becomes inconsistent. The flags are:
$ python -c "import sysconfig; print(sysconfig.get_config_var('CFLAGS'))"
-fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG
-fcf-protection -fexceptions -fcf-protection -fexceptions -fcf-protection
-fexceptions
-O3
I'd argue that the goal is to have flags that provide a reasonable
efficient default that integrates well with the cpython code provided
by the distribution,
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
should be included too. (Those flags allow whole-system profiling of
the system, and this works best if all of the system has frame pointers,
so the extensions should have them too.)
I'd argue that whoever wants to profile their system using frame pointers is
also capable of setting the flags for the extension modules their build themselves.
Also, can we get of rid of the repeats?
I agree we should.
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: The RPM pyproject Declarative Buildsystem is available in Rawhide
On 25. 07. 24 23:13, Miro Hrončok wrote: 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. I just found out Koji will fail buildSRPMFromSCM whent he spec file uses %autorelease/%autochangelog with BuildSystem because the rpmautospec plugin cannot parse spec files with RPM 4.20+ features. Reported as: https://pagure.io/fedora-infrastructure/issue/12126 -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Default BuildOption(install) for the RPM pyproject declarative buildsystem
On 22. 07. 24 19:00, Miro Hrončok wrote: On 03. 07. 24 15:00, Tomáš Orsava wrote: On 7/3/24 12:07, Miro Hrončok wrote: 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. I prefer option 1. This is something the users *should* actively check and verify, so having 1 extra line for it seems reasonable to me. We're still saving dozen+ lines of boilerplate and replacing it with one line of meaningful input. That's much easier to use in view. On 03. 07. 24 15:14, Petr Viktorin wrote: > Hello, > I recommend starting out with the explicit option. Requiring > BuildOption(install) sounds good, and can be changed to a better default > after people get some experience with the system. This is now implemented in the original PR (as a fixup commit): https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/455 As a followup, I got another idea: No BuildOption(install) -> no %pyproject_save_files That would also work but it would allow folks who don't want to use %pyproject_save_files to also use the declarative build system without overriding %install. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: The -O3 flag leaked into sysconfig CFLAGS, should we keep it?
On 06. 08. 24 1:20, Miro Hrončok wrote:
Hello Pythonistas.
For years, the CFLAGS embedded in Python sysconfig contained -O2 in Fedora.
This was how Python was built and by default, all flags used to build Python
were embedded.
Later, the flag was removed in Fedora 39 via this change:
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags_Reduction
We wanted to remove as many flags as possible, with this motivation:
"""
Python developers will get more upstream-like experience when building Python
extension modules and also closer to building vanilla C programs.
"""
Note that removing -O2 specifically was not the primary motivation, but the
removal was intentional at that time.
Now we build Python 3.13 with -O3 via this change:
https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3
The change proposal said:
"""
Other Python extension modules will remain bulidng as before, e.g. in RPM
packages, they will still be built with -O2...
"""
However, I made a mistake and the -O3 flag leaked into sysconfig CFLAGS.
The good news is this does not seem to affect RPM packages, they are still
being built with -O2, like this:
<$CFLAGS from automatic %set_build_flags>
E.g. ... -fcf-protection -fexceptions -O3 -O2 -flto=auto ...
The latter flag wins.
OTOH users building their own extension modules will get -O3.
This is not what was intended. However, "Python developers will get more
upstream-like experience" is more true now, because upstream Python builds use
-O3:
$ podman run --rm -ti python:3.12 /usr/bin/bash
# python
>>> import sysconfig
>>> sysconfig.get_config_var('CFLAGS')
'-fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall'
So the question is:
Do we keep -O3 for user-built extension modules for speed and upstream-like
experience? (I would update the -O3 change proposal.)
Or do we loose the flag, as currently documented?
Alternatively, do something else entirely (e.g. embed -O2, or other flag...)?
I slept on it and I support keeping the -O3 flag in sysconfig CFLAGS.
The original motivation for Python_Extension_Flags_Reduction was:
"""
Python developers will get more upstream-like experience when building Python
extension modules and also closer to building vanilla C programs.
"""
Keeping -O3 supports "more upstream-like experience".
Getting rid of it supports "closer to building vanilla C programs".
When choosing from the two, I prefer the first one.
Every time somebody pip installs something without a wheel, or even builds
their own extension module code, on CI etc. they would benefit from the added
speed. If we want Fedora to succeed on the CI field, we should be competitive.
The benchmarks used to measure the -O2 -> -O3 transition were also measured
with -O3 in sysconfig CFLAGS, so if they build some custom C code, it might
have impacted the results.
If nobody speaks up against keeping the flag, I'll amend the change proposal
and submit it for FESCo re-approval.
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
The -O3 flag leaked into sysconfig CFLAGS, should we keep it?
Hello Pythonistas.
For years, the CFLAGS embedded in Python sysconfig contained -O2 in Fedora.
This was how Python was built and by default, all flags used to build Python
were embedded.
Later, the flag was removed in Fedora 39 via this change:
https://fedoraproject.org/wiki/Changes/Python_Extension_Flags_Reduction
We wanted to remove as many flags as possible, with this motivation:
"""
Python developers will get more upstream-like experience when building Python
extension modules and also closer to building vanilla C programs.
"""
Note that removing -O2 specifically was not the primary motivation, but the
removal was intentional at that time.
Now we build Python 3.13 with -O3 via this change:
https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3
The change proposal said:
"""
Other Python extension modules will remain bulidng as before, e.g. in RPM
packages, they will still be built with -O2...
"""
However, I made a mistake and the -O3 flag leaked into sysconfig CFLAGS.
The good news is this does not seem to affect RPM packages, they are still
being built with -O2, like this:
<$CFLAGS from automatic %set_build_flags>
E.g. ... -fcf-protection -fexceptions -O3 -O2 -flto=auto ...
The latter flag wins.
OTOH users building their own extension modules will get -O3.
This is not what was intended. However, "Python developers will get more
upstream-like experience" is more true now, because upstream Python builds use -O3:
$ podman run --rm -ti python:3.12 /usr/bin/bash
# python
>>> import sysconfig
>>> sysconfig.get_config_var('CFLAGS')
'-fno-strict-overflow -Wsign-compare -DNDEBUG -g -O3 -Wall'
So the question is:
Do we keep -O3 for user-built extension modules for speed and upstream-like
experience? (I would update the -O3 change proposal.)
Or do we loose the flag, as currently documented?
Alternatively, do something else entirely (e.g. embed -O2, or other flag...)?
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
The RPM pyproject Declarative Buildsystem is available in Rawhide
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/README.md
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
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Default BuildOption(install) for the RPM pyproject declarative buildsystem
On 24. 07. 24 6:01, Neal Gompa wrote:
On Mon, Jul 22, 2024 at 1:01 PM Miro Hrončok wrote:
On 03. 07. 24 15:00, Tomáš Orsava wrote:
On 7/3/24 12:07, Miro Hrončok wrote:
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.
I prefer option 1. This is something the users *should* actively check and
verify, so having 1 extra line for it seems reasonable to me. We're still
saving dozen+ lines of boilerplate and replacing it with one line of meaningful
input. That's much easier to use in view.
On 03. 07. 24 15:14, Petr Viktorin wrote:
> Hello,
> I recommend starting out with the explicit option. Requiring
> BuildOption(install) sounds good, and can be changed to a better default
> after people get some experience with the system.
This is now implemented in the original PR (as a fixup commit):
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/455
Could we expand on this with dynamic subpackages to support building
against multiple Python versions from a single source package and
producing flavor subpackages against each Python version enabled?
I don't have the proper energy:motivation ratio to do that at this moment. It
seems possible with nowadays RPM, but there are definitively challenges.
If I did this, I would not try to expand the declarative buildsystem, I'd try
to design this first without it and only later hook it up into that.
---
Why do you think it should be the declarative buildsystem specifically that
would benefit form this?
At the current state, it merely replaces the %prep, %generate_buildrequires,
%build, %install, and %check sections.
We could explore the possibility to use the RPM 4.19 Dynamic Spec Generation to
generate the %package and %files section from within %install or %build and
enable this in the pyproject declarative buildsystem by default. The main issue
with this approach is that the more options we need to pass to the Declarative
Buildsystem, the more incomprehensible the invocation is.
Compare:
%pyproject_save_files -l pello
...
%files -n python3-pello -f %{pyproject_files}
%doc README.md
%{_bindir}/pello_greeting
With something like this:
BuildOption(install): -l pello --doc README.md --bindir pello_greeting
Sure, the latter is shorter but also quite cryptic.
---
Anyway, as a demo, I think it should be fairly simple to generate this
automatically from package %{name}:
%package -n python3-pello
Summary:%{summary}
%description -n python3-pello
...
The biggest challenge is the value of the %description.
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Default BuildOption(install) for the RPM pyproject declarative buildsystem
On 03. 07. 24 15:00, Tomáš Orsava wrote: On 7/3/24 12:07, Miro Hrončok wrote: 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. I prefer option 1. This is something the users *should* actively check and verify, so having 1 extra line for it seems reasonable to me. We're still saving dozen+ lines of boilerplate and replacing it with one line of meaningful input. That's much easier to use in view. On 03. 07. 24 15:14, Petr Viktorin wrote: > Hello, > I recommend starting out with the explicit option. Requiring > BuildOption(install) sounds good, and can be changed to a better default > after people get some experience with the system. This is now implemented in the original PR (as a fixup commit): https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/455 -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to pass configuration options to %pyproject_wheel
On 07. 07. 24 22:05, Sandro wrote:
On 07-07-2024 19:57, Antonio T. sagitter wrote:
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"
I believe `-C--enable-qcas` is waht you are looking for. It's explained in the
pyproject-rpm-macros README, which is what you see when visiting
https://src.fedoraproject.org/rpms/pyproject-rpm-macros (search for / scroll
down to "Passing config settings to build backends").
If the project uses setuptools, you might need to use:
%pyproject_wheel -C--global-option=--enable-qcas
Because that's how setuptools expects configuration key=value pairs.
--
Miro Hrončok
--
Phone: +420777974800
Fedora Matrix: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Default BuildOption(install) for the RPM pyproject declarative buildsystem
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
--
___
python-devel mailin
Re: Handling --enable-experimental-jit in Python 3.13
On 24. 06. 24 23:08, Fabio Valentini wrote: On Mon, Jun 24, 2024 at 3:53 PM Miro Hrončok wrote: On 17. 04. 24 18:40, Victor Stinner wrote: On Wed, Apr 17, 2024 at 2:38 PM Miro Hrončok wrote: Victor, do you think it would be possible to build in the JIT support but have a runtime opt-out/opt-in switch? That way, we can build it, but disable it by default, unless our users want to experiment with it. PEP 744 "JIT Compilation" informal PEP is being discussed. I asked your question there: https://discuss.python.org/t/pep-744-jit-compilation/50756/33 The JIT support was built on x86_64+aarch64, on Fedora 40+ Set the PYTHON_JIT environment variable to 1 to enable it on runtime. So this means that the JIT-enabled Python is not, as initially expected, a separate build, but something that can be enabled in existing builds by passing this environment variable instead? Nice! Exactly. The fact that it is built in might still create some regressions, but if the opt-in mechanism works correctly, only those who want the JIT will have it. -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Handling --enable-experimental-jit in Python 3.13
On 17. 04. 24 18:40, Victor Stinner wrote: On Wed, Apr 17, 2024 at 2:38 PM Miro Hrončok wrote: Victor, do you think it would be possible to build in the JIT support but have a runtime opt-out/opt-in switch? That way, we can build it, but disable it by default, unless our users want to experiment with it. PEP 744 "JIT Compilation" informal PEP is being discussed. I asked your question there: https://discuss.python.org/t/pep-744-jit-compilation/50756/33 The JIT support was built on x86_64+aarch64, on Fedora 40+ Set the PYTHON_JIT environment variable to 1 to enable it on runtime. F41 (stable) https://bodhi.fedoraproject.org/updates/FEDORA-2024-ecfa04265a F40 (pending) https://bodhi.fedoraproject.org/updates/FEDORA-2024-a5a0be41ba -- Miro Hrončok -- Phone: +420777974800 Fedora Matrix: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora 41 Python 3.13 mass rebuild status
On 10. 06. 24 17:34, Karolina Surma wrote: Hello, The Python 3.13 rebuild is in progress. We plan to merge the side tag soon. So far, we've successfully built 3528 out of 4109 source packages, with 581 remaining to be built. See the list of packages sorted by maintainers at the end of this mail. If your package fails because there is a non-dependency problem, you might have already received a bugzilla from us in the past. If the build failure is related to changes in Python 3.13, it should contain some hints about the problem. If you haven't received a bugzilla from us yet, feel free to open a new one and block the PYTHON3.13 tracking bug. You can verify your package builds with Python 3.13 via a scratch build: $ koji build --scratch f41-python or $ fedpkg build --scratch --target f41-python If successful, you can submit a build to the side tag from the rawhide branch in dist-git repository via: $ fedpkg build --target f41-python Please, don't build Python packages in regular rawhide now. After the side tag is merged, we'll let you know when it's safe to build in regular rawhide again. The remaining failures can be fixed afterwards. I requested the side tag to be merged. https://pagure.io/releng/issue/12155 If you build for f41-python now, there is a risk that the build will fail at tagging time if the side tag is merged during the build. I don't recommend building long builds. Please, still don't build Python packages in rawhide until the side tag is fully merged. Thank you for your patience. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 41 Python 3.13 rebuilds to start in a side tag (hopefully) next week
On 10. 06. 24 15:07, Tom Stellard wrote: On 5/31/24 01:55, Karolina Surma wrote: Hello, To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.13 Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available. TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13. Details: If you see a "Rebuilt for Python 3.13" (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=f41-python $ koji wait-repo f41-python --build I'm in the middle of updating the LLVM packages in my own side tag, would it work if I tag python3.13.0b2 into my LLVM side-tag and rebuild the LLVM packages there? It works if you merge your side tag later than ours. If you merge it sooner, it breaks the world unless you untag python first (which would presumably break the Python packages built in your side tag). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 41 Python 3.13 rebuilds to start in a side tag (hopefully) next week
On 06. 06. 24 9:57, Sandro wrote: On 31-05-2024 10:55, Karolina Surma wrote: TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13. What about new packages? Can those be added to rawhide and will they be picked up for the rebuild? Or is it better to wait and submit them after the side tag has been merged? Feel free to add new packages, they will be picked. If you build them in rawhide, it will update the rawhide repo which we use as a source of our to-build package list. If you build them right before we merge the side tag, chances are the builds won't be part of the repo in time. In that case, we will rebuild it after the merge (as well as many others). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: are pyproject rpm macros supposed to pick up the license automatically?
On 29. 05. 24 9:48, Karolina Surma wrote: Hi Felix, The missing bit is whether the build backend of pypdf exposes the metadata that pyproject-rpm-macros use to detect the license file. pypdf uses flit-core as its build backend which doesn't implement `License-File` field (it's a part of PEP 639, still in draft and implemented only in a subset of build backends, like setuptools and hatch). Hopefully in the future it'll become a standard. For now, you've got to declare the license file via the %license macro manually. See "Generating the %files section" of https://src.fedoraproject.org/rpms/pyproject-rpm-macros/blob/rawhide/f/README.md for more details. Most importantly, this paragraph: """ %pyproject_save_files can automatically mark license files with %license macro and language (*.mo) files with %lang macro and appropriate language code. Only license files declared via PEP 639 License-File field are detected. PEP 639 is still a draft and can be changed in the future. It is possible to use the -l flag to declare that a missing license should terminate the build or -L (the default) to explicitly disable this check. Packagers are encouraged to use the -l flag when the %license file is not manually listed in %files to avoid accidentally losing the file in a future version. When the %license file is manually listed in %files, packagers can use the -L flag to ensure future compatibility in case the -l behavior eventually becomes a default. """ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Creating venv with latest python3.10 requires expat >= 2.6.0
On 18. 04. 24 1:00, Miro Hrončok wrote: On 18. 04. 24 0:37, Miro Hrončok wrote: On 17. 04. 24 23:10, Markus Falb wrote: I wonder if there is a way to reflect that in the spec file something like: ...snip Requires: expat >= 2.6.0 snap... Yes, we need to do that. I'm on it. https://src.fedoraproject.org/rpms/python3.13/pull-request/54 -- other Pythons will follow after CI + review. Here is the Fedora 38 python3.10 update: https://bodhi.fedoraproject.org/updates/FEDORA-2024-7736b7ce48 Other updates are available as well: https://bodhi.fedoraproject.org/updates/?packages=python3.8,python3.9,python3.10,python3.11,python3.12,python3.13 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Creating venv with latest python3.10 requires expat >= 2.6.0
On 18. 04. 24 0:37, Miro Hrončok wrote: On 17. 04. 24 23:10, Markus Falb wrote: I wonder if there is a way to reflect that in the spec file something like: ...snip Requires: expat >= 2.6.0 snap... Yes, we need to do that. I'm on it. https://src.fedoraproject.org/rpms/python3.13/pull-request/54 -- other Pythons will follow after CI + review. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Creating venv with latest python3.10 requires expat >= 2.6.0
On 17. 04. 24 23:10, Markus Falb wrote: Hi, I noticed that creating virtualenvs did not work anymore with the latest python 3.10 package on Fedora 38 Hello Markus, Thanks for the report, this is indeed happening. [root@fe60c84b08f3 /]# python3.10 -m venv venv Error: Command '['/venv/bin/python3.10', '-m', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1. snap... And the error is (when I run the failed command): ImportError: /usr/lib64/python3.10/lib-dynload/pyexpat.cpython-310-x86_64-linux-gnu.so: undefined symbol: XML_SetReparseDeferralEnabled Unfortunately this also happens with all python3.8 ... python3.13. 3.11 and 3.12 were still in updates testing, so I have blocked the autopush for now: https://bodhi.fedoraproject.org/updates/FEDORA-2024-d615822702 https://bodhi.fedoraproject.org/updates/FEDORA-2024-98a723cb68 I am afraid this also impacts newer Fedoras once shipped with older expat. https://www.python.org/downloads/release/python-31014/ tells us ... bundled libexpat was updated to 2.6.0 to address CVE-2023-52425... And we unbundle it, yet we depend on the new symbol :( using the fedora container for CI runs without doing global dnf update to save resources I had to update expat from expat-2.5.0-2.fc38.x86_64 to expat-2.6.0-1.fc38.x86_64 Fortunately, fedora:39 from registry.fedoraproject.org already has expat-2.6.2-1.fc39. I wonder if there is a way to reflect that in the spec file something like: ...snip Requires: expat >= 2.6.0 snap... Yes, we need to do that. I'm on it. --- I wonder how to prevent this in the future. There is https://github.com/rpm-software-management/rpm/pull/2372 but that will take a while. Perhaps we need to always Require expat >= version of expat used when building. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Handling --enable-experimental-jit in Python 3.13
On 17. 04. 24 14:27, Victor Stinner wrote: On Wed, Apr 10, 2024 at 8:23 PM Miro Hrončok wrote: Python 3.13 has an experimental JIT compiler: https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler Enabling it is a configure (hence build-time) option. How do we handle this in Fedora? - We can keep it disabled, as it is experimental. I concur with that. - We can enable it, but be ready to revert if it causes problems. - We can add yet another build variant, but we already have 4 of those (regular, debug, freethreading, freethreading-debug), so I'd rather not make it 6 (or 8, if we include freethreading+jit combinations). I don't know yet if it would be co-installable. I don't think it's worth it. Moreover, it doesn't build on Fedora 39 with clang-17, since Python 3.13 currently requires exactly clang-16. We have multiple clangs/llvms: https://src.fedoraproject.org/rpms/llvm16 https://src.fedoraproject.org/rpms/clang16 Victor, do you think it would be possible to build in the JIT support but have a runtime opt-out/opt-in switch? That way, we can build it, but disable it by default, unless our users want to experiment with it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RFC: Django latest vs LTS maintenance plan
On 11. 04. 24 22:41, Michel Lind wrote: The different Django stacks are in the process of being updated so they can be swapped without affecting dependents, by providing and conflicting with the virtual `python-django-impl`; not only will this allow us to swap one Django LTS for another in EPEL when the older one EOLs, but it also allows those with dependencies that are not qualified for the latest Django to swap to the LTS in Fedora I saw this and I meant to ask: Why `python-django-impl`? Why not `Conflicts: pytohn3dist(django)`? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Idea: pynose as drop-in replacement for nose
On 11. 04. 24 15:05, Sandro wrote: On 11-04-2024 13:54, Miro Hrončok wrote: On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. That makes sense. Review is up [1]. If enough packagers adapt, I may not need to go through the changes process. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. Since predicting the future is difficult, I'll start on writing up a proposal while the package is being introduced, anyway. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2274514 I see "# Package doesn't provide any tests" in the %check section. That certainly feels a bit dodgy. This successor of a test framework decided to ditch all of the tests it used to have? That is certainly a red flag. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Idea: pynose as drop-in replacement for nose
On 11. 04. 24 11:55, Sandro wrote: While I ponder those thoughts some more, moving forward in either direction, the next step would be writing a change proposal? I'd start by: Packaging pynose without hacks (only making it Conflict with nose, no compatibility Provides, Obsoletes or dist-infos). That way, pro-active packagers can switch already. And the change proposal can then describe what will be *added* to pynose, rather than describing the approach from scratch. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Handling --enable-experimental-jit in Python 3.13
Hello Pythonistas, Python 3.13 has an experimental JIT compiler: https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler Enabling it is a configure (hence build-time) option. How do we handle this in Fedora? - We can keep it disabled, as it is experimental. - We can enable it, but be ready to revert if it causes problems. - We can add yet another build variant, but we already have 4 of those (regular, debug, freethreading, freethreading-debug), so I'd rather not make it 6 (or 8, if we include freethreading+jit combinations). I don't know yet if it would be co-installable. Opinions? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Idea: pynose as drop-in replacement for nose
On 10. 04. 24 17:30, Sandro wrote: On 10-04-2024 12:04, Miro Hrončok wrote: On 09. 04. 24 19:30, Sandro wrote: Therefore, I'm thinking of introducing pynose as a drop in replacement of deprecated nose. Pynose uses the same namespace as nose, but provides python3dist(pynose). Thus adding Provides: for nose would make it a drop-in replacement for packages currently depending on nose. FTR We MUST NOT add RPM Provides for python3dist(nose) unless we package nose dist-info metadata. Thanks for pointing that out. I was indeed experimenting with it. Is there some documentation or example for packaging extra dist-info metadata? Not really, because it is a hack that should not be done if it can be avoided. You can see a working example in python-lark https://src.fedoraproject.org/rpms/python-lark/c/c7a9aa2e7b0b1d9d621ac60f73c854fdcc154ab2 I also played around pith setuptools' `provide` only to learn later on that pip ignores it entirely (as well as `obsoletes`, which is deprecated). So, the pyproject-rpm-macros are probably not honoring that either. For example %pyproject_buildrequires queries Python for installed packages (hence it reads the packaged dist-info/egg-info metadata) and it will see nose is not installed. It will then query dnf to install python3dist(nose). dnf will install pynose. %pyproject_buildrequires will see nose is not installed. It will query dnf to install python3dist(nose) again. dnf will install nothing. The %pyproject_buildrequires phase will end prematurely when dnf installs nothing. Agreed. If we do add python3dist(nose) it needs to work not cause more issues. Most packages I've looked at recently have a BR for python3-nose. That's covered by adding "%py_provides python3-nose". But dependency resolution in %pyproject_buildrequires uses python3dist. If the package configuration has a dependency on nose declared, I would like that to be satisfiable, both in RPM and pip, by installing python3-pynose. If that is too much hassle or simply (currently) not possible, a fallback to not providing nose at all, is also possible. In that case more packages might need to be patched and we need to educate people te replace dependencies on nose with pynose. My preference at the moment is for the former. If we are to retire python-nose at the same time, I'd do: - have python3-pynose %py_provides (and Obsolete) python3-nose - don't mess with dist metadata at all That way: - packages that use upstream requirements will need to be updated (preferably upstream first => good) - packages that manually BuildRequire python3-nose will likely keep working If the pynose package has a "nose" importable module, providing python3-nose even follows https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_provides_for_importable_modules -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Idea: pynose as drop-in replacement for nose
On 09. 04. 24 19:30, Sandro wrote: Therefore, I'm thinking of introducing pynose as a drop in replacement of deprecated nose. Pynose uses the same namespace as nose, but provides python3dist(pynose). Thus adding Provides: for nose would make it a drop-in replacement for packages currently depending on nose. FTR We MUST NOT add RPM Provides for python3dist(nose) unless we package nose dist-info metadata. For example %pyproject_buildrequires queries Python for installed packages (hence it reads the packaged dist-info/egg-info metadata) and it will see nose is not installed. It will then query dnf to install python3dist(nose). dnf will install pynose. %pyproject_buildrequires will see nose is not installed. It will query dnf to install python3dist(nose) again. dnf will install nothing. The %pyproject_buildrequires phase will end prematurely when dnf installs nothing. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: %pyproject_buildrequires -r/-x: Attempt to read runtime dependencies from pyproject.toml?
On 27. 03. 24 23:15, Maxwell G wrote: 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. Yeah, I think -p (for *p*yproject) is good flag name choice. Or even for [*p*roject] table. It is double good. I guess I will throw something out there, but I am not convinced it is a great idea: what about making the `-p` flag fail if `prepare_metadata_for_build_wheel` is available? In my opinion, this should only be a last resort for backends that do not implement the hook. I am not particularly keen on this. This means that once the backend starts supporting it, all the spec files using -p need to drop it. And if the backend only supports it in rawhide, the spec files need to diverge and/or %if-guard the flag. If the backend followed PEP 621 before adding the hook and now it added the hook, it is unlikely the PEP 621 support was dropped. OTHO if the backed was changed (e.g. meson -> poetry), this *could* happen. So I am not entirely opposed for this guard. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaned python-mccabe (dependency of pylint)
Hello.
I have orphaned python-mccabe.
It does not build with updated hypothesis, because the update broke
hypothesmith and I don't have time to look into it:
https://bugzilla.redhat.com/2261579
mccabe is a dependency of pylint.
Packages other than linters should not BuildRequire pylint in Fedora (but they
do).
The recursive dependency tree is very large. Here are some basics:
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mccabe
pylint-0:3.0.3-3.fc40.src
python-f5-icontrol-rest-0:1.3.15-11.fc39.src
python-flake8-0:6.0.0-2.fc39.src
python-lsp-server-0:1.9.0-3.fc40.src
python-twitter-0:3.5-18.fc39.src
python3-flake8-0:6.0.0-2.fc39.noarch
python3-lsp-server+all-0:1.9.0-3.fc40.noarch
python3-pylint-0:3.0.3-3.fc40.noarch
$ repoquery -q --repo=rawhide{,-source} --whatrequires pylint --whatrequires
python3-pylint
crypto-policies-0:20231204-1.git1e3a2e4.fc40.src
distro-info-0:0.18-18.fc39.src
dogtag-pki-tests-0:11.4.3-2.fc39.1.noarch
foomuuri-0:0.21-1.fc40.src
nordugrid-arc-0:6.18.0-2.fc40.src
nvme-stas-0:2.3.1-1.fc40.src
postfix-mta-sts-resolver+dev-0:1.4.0-2.fc40.noarch
pylint-0:3.0.3-3.fc40.noarch
python-geoplot-0:0.5.1-7.fc40.src
python-guessit-0:3.8.0-1.fc40.src
python-hwdata-0:2.3.8-4.fc39.src
python-platformio-0:6.1.13-1.fc40.src
python-pocketlint-0:0.25-1.fc40.src
python-pylint-venv-0:3.0.2-1.fc40.src
python-rebulk-0:3.3.0-1.fc40.src
python3-pocketlint-0:0.25-1.fc40.noarch
python3-spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.noarch
thonny-0:4.1.4-1.fc40.noarch
thonny-0:4.1.4-1.fc40.src
vcs-diff-lint-0:4-3.fc39.noarch
vim-syntastic-python-0:3.10.0-21.fc39.noarch
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-mccabe
--recursive
crypto-policies-0:20231204-1.git1e3a2e4.fc40.src
diskimage-builder-0:3.31.0-2.fc40.noarch
distro-info-0:0.18-18.fc39.src
dogtag-pki-tests-0:11.4.3-2.fc39.1.noarch
foomuuri-0:0.21-1.fc40.src
glances-0:3.4.0-3.fc39.src
mu-0:1.2.0-10.fc40.noarch
mu-0:1.2.0-10.fc40.src
nordugrid-arc-0:6.18.0-2.fc40.src
nvme-stas-0:2.3.1-1.fc40.src
ocaml-atd-0:2.15.0-3.fc40.src
piper-0:0.7-5.fc39.src
postfix-mta-sts-resolver+dev-0:1.4.0-2.fc40.noarch
pyee-0:9.0.4-6.fc39.src
pylint-0:3.0.3-3.fc40.noarch
pylint-0:3.0.3-3.fc40.src
python-binary-memcached-0:0.31.2-2.fc39.src
python-croniter-0:1.4.1-1.fc40.src
python-debianbts-0:2.8.2-13.fc39.src
python-django-formtools-0:2.2-10.fc39.src
python-esbonio-0:0.16.4-3.fc40.src
python-f5-icontrol-rest-0:1.3.15-11.fc39.src
python-factory-boy-0:3.3.0-1.fc40.src
python-flake8-0:6.0.0-2.fc39.src
python-flake8-builtins-0:2.1.0-4.fc39.src
python-flake8-comprehensions-0:3.10.1-6.fc39.src
python-flake8-import-order-0:0.18.2-3.fc39.src
python-flake8-polyfill-0:1.0.2-19.fc39.src
python-flake8-quotes-0:3.3.2-4.fc39.src
python-flask-mailman-0:1.0.0-1.fc40.src
python-geoplot-0:0.5.1-7.fc40.src
python-gerritlib-0:0.6.0-24.fc39.src
python-guessit-0:3.8.0-1.fc40.src
python-hacking-0:6.0.1-1.fc40.src
python-hwdata-0:2.3.8-4.fc39.src
python-ipmi-0:0.5.4-3.fc39.src
python-lsp-server-0:1.9.0-3.fc40.src
python-nashpy-0:0.0.40-1.fc39.src
python-nikola-0:8.2.4-4.fc39.src
python-oslo-context-0:5.2.0-1.fc40.src
python-oslo-service-0:3.1.1-8.fc40.src
python-pep8-naming-0:0.13.3-3.fc39.src
python-platformio-0:6.1.13-1.fc40.src
python-pocketlint-0:0.25-1.fc40.src
python-pylint-venv-0:3.0.2-1.fc40.src
python-pymochad-0:0.2.0-10.fc39.src
python-pytest-flake8-path-0:1.5.0-1.fc39.src
python-rebulk-0:3.3.0-1.fc40.src
python-sqlalchemy-utils-0:0.41.1-2.fc39.src
python-twitter-0:3.5-18.fc39.src
python3-esbonio+dev-0:0.16.4-3.fc40.noarch
python3-flake8-0:6.0.0-2.fc39.noarch
python3-flake8-builtins-0:2.1.0-4.fc39.noarch
python3-flake8-comprehensions-0:3.10.1-6.fc39.noarch
python3-flake8-docstrings-0:1.6.0-6.fc39.noarch
python3-flake8-import-order-0:0.18.2-3.fc39.noarch
python3-flake8-polyfill-0:1.0.2-19.fc39.noarch
python3-flake8-quotes-0:3.3.2-4.fc39.noarch
python3-hacking-0:6.0.1-1.fc40.noarch
python3-lsp-server+all-0:1.9.0-3.fc40.noarch
python3-oslo-concurrency-tests-0:5.2.0-1.fc40.noarch
python3-oslo-service-tests-0:3.1.1-8.fc40.noarch
python3-oslo-utils-tests-0:6.2.1-1.fc40.noarch
python3-pep8-naming-0:0.13.3-3.fc39.noarch
python3-pocketlint-0:0.25-1.fc40.noarch
python3-pylint-0:3.0.3-3.fc40.noarch
python3-pytest-flake8-path-0:1.5.0-1.fc39.noarch
python3-spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.noarch
python3-tackerclient-tests-unit-0:1.14.0-1.fc40.noarch
quodlibet-0:4.6.0-1.fc40.src
repo-0:2.35-1.fc39.src
spyder-0:6.0.0~a1-13.20231010gitv6.0.0a1.fc40.src
thonny-0:4.1.4-1.fc40.noarch
thonny-0:4.1.4-1.fc40.src
vcs-diff-lint-0:4-3.fc39.noarch
vim-syntastic-python-0:3.10.0-21.fc39.noarch
xr-hardware-0:1.1.0-1.fc40.src
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-co
Re: Orphaning python-flit
On 26. 01. 24 4:33, Nico Kadel-Garcia wrote: What is the*fascination* with splitting and renaming packages this way? No idea generally, but in the world of Python packaging, the two cases I know (poetry, flit) were motivated by folks not wanting to pull in full-blown package and environment management apps when they only want to pip install something that uses it. The split made a lot of sense. core - PEP517 backend https://peps.python.org/pep-0517/ the rest - an app that let's you "manage" your project Scenario: - The developer uses the full app to create and develop the project. - The user uses -core to build and install it. (Obviously a developer is free to just use -core as well, if they like it. Many upstream projects use flit-core only.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Orphaning python-flit
Hello.
Now when python-flit-core has been split out of python-flit, I do no longer
have a use-case for python-flit and hence I have orphaned it.
$ repoquery -q --repo=rawhide{,-source} --whatrequires flit
python-perky-0:0.8.2-3.fc39.src
python-pydyf-0:0.8.0-1.fc40.src
python-pyrpm-0:0.14.1-3.fc39.src
python-signature-dispatch-0:1.0.1-4.fc39.src
python-vecrec-0:0.3.1-11.fc40.src
weasyprint-0:60.2-1.fc40.src
The packages would probably build fine with flit-core (happy to help with that
if you are interested).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Broken %pyproject_buildrequires parser
On 29. 12. 23 20:41, Mattia Verga wrote: I think I would just do something like this in %prep: sed -r -i 's/^file:/# &/' tests/requirements.in Thanks, that did it. Is this something broken in upstream code, or is it our parser that needs to be adjusted? Our thing wants to generate dependencies on packages via their names. It cannot properly generate dependencies for file:, https:, git, etc. packages. What should the parser do? We could generate a dependency on python3dist(rpds-py), but it woulds be wrong, this package does not BuildRequire self, it just wants to be installed. It isn't broken in upstream, it's just a tad weird. What upstream does here is using the tests/requirements.in file for a slightly different purpose than we do. Their purpose: describe everything we want installed in the test environment. Our purpose: list the dependencies for tests. Similar or not, the self-dependency is the difference. And unlike other types of BuildRequires we can generate, generating them from a file is non-standardized, so we cannot go to upstream and say "your text file is wrong", because it's just that -- a text file. I couldn't find the relevant pip documentation about 'file:.#egg=' format. file: -> this will be a local path on the filesystem . -> the actual path #egg=rpds-py -> this package is called rpds-py (a hint to pip to know this information before actually going to the path and building a package) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: python packaging assistance sought for xgboost
On 12. 12. 23 7:56, Nathan Scott wrote: Thanks Miro - that size pointer was helpful. Indeed, the only thing in the wheel are 3 metadata files. Things seem to be OK up to this point in the upstream hatchling build: https://github.com/dmlc/xgboost/blob/43897b829680d241491abe1ecd46b2ba9d338967/python-package/packager/pep517.py#L86 ... that temporary directory is populated with all the python files in what looks like a good format, but the generated wheel is essentially empty. Is there any way to see what's happening inside that hatchling.build.build_wheel call I wonder? I don't know. Try adding: [tool.hatch.build.targets.wheel] packages = ["xgboost"] to pyproject.toml. Does it help? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
pyproject-rpm-macros 1.11.0: %pyproject_save_files gains the -l flag (and more)
Hello Pythonistas,
pyproject-rpm-macros 1.11.0 is available in Rawhide + updates-testing for older
releases.
https://bodhi.fedoraproject.org/updates/?packages=pyproject-rpm-macros
I plan to sync it to c9s eventually early next year.
It contains one new feature and several smaller bugfixes:
The new -l/-L flag to %pyproject_save_files
===
As said by Maxwell G on this list [1]:
%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.
You can now use `%pyproject_save_files -l` to assert at least one license file
was detected and marked as %license. This is good in case you want a protection
from an accidental silent drop of the %license file in a next release.
Note that the -l flag only asserts *at least one license file was detected*.
It can still mean one of multiple files are silently dropped during a package
upgrade, but that's unlikely to happen for unrelated reasons (such as a change
of a build backend upstream).
For the time being, this assertion is opt-in only. Use `%pyproject_save_files
-L` if you list the %license file manually and you would like to explicitly
opt-out from this check in case it ever becomes the default (no such plan
exists for the time being).
(Note that this still needs to be documented in the Python packaging
guidelines.)
Prevent incorrect usage of %pyproject_buildrequires -R with -x/-e/-t
Using `%pyproject_buildrequires -R` with -x, -t, or -e previously silently
discarded the -R option. Combining either of the flags with -R is actually not
possible and will now error properly.
https://bugzilla.redhat.com/2244282
Show a better error message when %pyproject_install finds no wheel
==
When there is no wheel to install (e.g. when you forget to run
%pyproject_wheel), the underlying pip error message was leaking:
ERROR: You must give at least one requirement to install (maybe you meant "pip
install /builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir"?)
It has been explicitly changed to:
ERROR: %pyproject_install found no wheel in %{_pyproject_wheeldir}
/builddir/build/BUILD/Pello-1.0.4/pyproject-wheeldir
https://bugzilla.redhat.com/2242452
Fix %pyproject_buildrequires -w when build backend is installed and pip isn't
=
Packages using `%pyproject_buildrequires -w` would fail to build if the build
backend was already (manually) installed before pip.
This was happening e.g. when testing a local version of the RPM with the build
backend and running something like:
$ mock init
$ mock install ../my-rpms/pytohn3-hatchling-1.2.3-1.fc50.noarch.rpm
$ fedpkg mockbuild -N
But it was also possible to achieve with manual BuildRequires:
BuildRequires: pytohn3-hatchling
...
%generate_buildrequires
%pyproject_buildrequires -w
The %pyproject_buildrequires macro generated a BuildRequires on pip, but it
attempted to build a wheel using pip before the generated pip dependency was
installed. This has now been fixed and the macro will "restart" in case pip is
not yet available to build the wheel.
https://bugzilla.redhat.com/2169855
---
Happy packaging.
Special thanks to Maxwell G, Karolina Surma, and Benjamin Beasley for help with
this release.
[1]
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/YDIHALW766GRSYU3GL635QER2MQABML6/
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archi
Re: Next Wednesday: Opening up the Python Maint Fedora Bugs Triage
On 06. 12. 23 13:28, Miro Hrončok wrote: Hello Pythonistas. Every other Wednesday at 14:00 Europe/Prague the Red Hat Python Maint team has a meeting at https://meet.google.com/xuj-jswy-hat The next meeting is in a week. We go trough the open Fedora Bugzillas, PRs etc. assigned to our members. https://fedoraproject.org/wiki/User:Python-maint We've been doing this for a while and recently we decided to open this meeting for other Python SIG members and interested parties. I've added the meeting to Fedora calendar: https://calendar.fedoraproject.org/SIGs/2023/12/11/#m10669 You are welcome to join us next week. I'll send a reminder. This is happening today at `date -d '2023-12-13 14:00 CET'`. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Heads up: dnf5 cannot handle BuildRequires with Python extras
Hello Pythonistas. In case you upgraded to mock-core-configs-39.3 and see failures like this in rawhide mockbuilds with %pyproject_buildrequires: No match for argument: python3dist(setuptools-scm[toml]) >= 5 No match for argument: python3dist(raven[flask]) No match for argument: python3dist(ini2toml[lite]) >= 0.9 Note that the issue is known and reported: https://github.com/rpm-software-management/dnf5/issues/1084 https://github.com/rpm-software-management/mock/issues/1267 This should block the deployment of https://fedoraproject.org/wiki/Changes/BuildWithDNF5 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: python packaging assistance sought for xgboost
On 10. 12. 23 23:05, Nathan Scott wrote: Thanks for the assistance Miro. I've uploaded a local build log here: https://nathans.fedorapeople.org/xgboost/build.log AFAICS the python parts of the %install step seemed to have worked, but based on Sandro's pointer I can see many files are missing. Building wheels for collected packages: xgboost Building wheel for xgboost (pyproject.toml): started Running command Building wheel for xgboost (pyproject.toml) Building wheel for xgboost (pyproject.toml): finished with status 'done' Created wheel for xgboost: filename=xgboost-2.0.2-py3-none-linux_aarch64.whl size=1413 sha256=e77e7765ce58907708363f8e60bf96ba11abd5f66bb78c1804f59bccdd4df36d There's not much information here, but size 1413 indicates the built wheel does not really have any Python modules in it. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: python packaging assistance sought for xgboost
On 08. 12. 23 7:22, Nathan Scott wrote:
Hi all,
I've recently been packaging xgboost for Fedora. It's a C++ project using
cmake, with a python module on the side (all in one source tarball):
https://nathans.fedorapeople.org/xgboost/
The dependent dmlc-core package is here:
https://nathans.fedorapeople.org/dmlc-core/
Everything is prepared and working from the C++ and shared library
perspectives, but I'm struggling with getting the python module to install
using latest Fedora python spec guidelines. Can anyone point out where I've
gone wrong? (looks like its during the final python step in the spec %install)
https://nathans.fedorapeople.org/xgboost/xgboost.spec+python shows my additions to add
the python sub-package and this is the error I now see (this is from the
"%pyproject_save_files xgboost" line right at the end of %install):
Traceback (most recent call last):
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 775, in
main(cli_args)
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 730, in main
file_section, module_names = pyproject_save_files_and_modules(
^
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 720, in
pyproject_save_files_and_modules
generate_file_list(paths_dict, globs, include_auto)
File "/usr/lib/rpm/redhat/pyproject_save_files.py", line 534, in
generate_file_list
raise ValueError(f"Globs did not match any module: {missed_text}")
ValueError: Globs did not match any module: xgboost
error: Bad exit status from /var/tmp/rpm-tmp.y91d9b (%install)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.y91d9b (%install)
Hello. As was already said, the error is that:
%pyproject_save_files xgboost
Finds no such Python modules.
If you could provide a full build log, it might indicate what Python modules
(if any) are actually installed.
Examining the wheels from https://pypi.org/project/xgboost/#files
xgboost-2.0.2-py3-none-manylinux2014_x86_64.whl
This one actually contains an xgboost Python module. That might indicate the
build step in %pyproject_wheel is somewhat broken. Without full logs, I cannot
say more.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Next Wednesday: Opening up the Python Maint Fedora Bugs Triage
Hello Pythonistas. Every other Wednesday at 14:00 Europe/Prague the Red Hat Python Maint team has a meeting at https://meet.google.com/xuj-jswy-hat The next meeting is in a week. We go trough the open Fedora Bugzillas, PRs etc. assigned to our members. https://fedoraproject.org/wiki/User:Python-maint We've been doing this for a while and recently we decided to open this meeting for other Python SIG members and interested parties. I've added the meeting to Fedora calendar: https://calendar.fedoraproject.org/SIGs/2023/12/11/#m10669 You are welcome to join us next week. I'll send a reminder. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: I propose sphinx no longer Requires sphinxcontrib-{applehelp,devhelp,jsmath,htmlhelp,serializinghtml,qthelp}
On 08. 11. 23 13:02, Miro Hrončok wrote: On 08. 11. 23 12:57, Neal Gompa wrote: Packages that need those would need to BuildRequire them specifically, as proposed in: -https://src.fedoraproject.org/rpms/xca/pull-request/1 -https://src.fedoraproject.org/rpms/python-django-haystack/pull-request/1 -https://src.fedoraproject.org/rpms/pykka/pull-request/3 -https://src.fedoraproject.org/rpms/extra-cmake-modules/pull-request/2 The change has been offered upstream, but I suppose it will take a while before it is actually landed there. Let me know if you think this needs more discussion before shipping it. (The change is only intended for Fedora 40+ and ELN.) Do we know what the impact of this is going to be beyond those four? All Fedora packages that BuildRequire python3-sphinx (even transitively) were tested. Those that successfully built before this change are known not to be impacted, except for the listed 4 and https://src.fedoraproject.org/rpms/python-fastavro/pull-request/12 (which is special, because the removal only uncovered a bug in tests). This was tested in https://copr.fedorainfracloud.org/coprs/churchyard/sphinxcontrib-optional/builds/ and https://copr.fedorainfracloud.org/coprs/churchyard/sphinxcontrib-mandaotry/builds/ A handful of packages timed out after 5 hours in Copr, happy to fix them later if they they are impacted. Same for the packages that FTBFS now for unrelated reasons. Another impacted package: https://src.fedoraproject.org/rpms/buildstream/pull-request/4 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: I propose sphinx no longer Requires sphinxcontrib-{applehelp,devhelp,jsmath,htmlhelp,serializinghtml,qthelp}
On 08. 11. 23 12:57, Neal Gompa wrote: Packages that need those would need to BuildRequire them specifically, as proposed in: -https://src.fedoraproject.org/rpms/xca/pull-request/1 -https://src.fedoraproject.org/rpms/python-django-haystack/pull-request/1 -https://src.fedoraproject.org/rpms/pykka/pull-request/3 -https://src.fedoraproject.org/rpms/extra-cmake-modules/pull-request/2 The change has been offered upstream, but I suppose it will take a while before it is actually landed there. Let me know if you think this needs more discussion before shipping it. (The change is only intended for Fedora 40+ and ELN.) Do we know what the impact of this is going to be beyond those four? All Fedora packages that BuildRequire python3-sphinx (even transitively) were tested. Those that successfully built before this change are known not to be impacted, except for the listed 4 and https://src.fedoraproject.org/rpms/python-fastavro/pull-request/12 (which is special, because the removal only uncovered a bug in tests). This was tested in https://copr.fedorainfracloud.org/coprs/churchyard/sphinxcontrib-optional/builds/ and https://copr.fedorainfracloud.org/coprs/churchyard/sphinxcontrib-mandaotry/builds/ A handful of packages timed out after 5 hours in Copr, happy to fix them later if they they are impacted. Same for the packages that FTBFS now for unrelated reasons. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
I propose sphinx no longer Requires sphinxcontrib-{applehelp,devhelp,jsmath,htmlhelp,serializinghtml,qthelp}
Hello Pythonistas. In https://src.fedoraproject.org/rpms/python-sphinx/pull-request/59 I propose a change that would make the runtime requirements of: - python3-sphinxcontrib-applehelp - python3-sphinxcontrib-devhelp - python3-sphinxcontrib-jsmath - python3-sphinxcontrib-htmlhelp - python3-sphinxcontrib-serializinghtml - python3-sphinxcontrib-qthelp ...optional (Recommends) in python3-sphinx. Packages that need those would need to BuildRequire them specifically, as proposed in: - https://src.fedoraproject.org/rpms/xca/pull-request/1 - https://src.fedoraproject.org/rpms/python-django-haystack/pull-request/1 - https://src.fedoraproject.org/rpms/pykka/pull-request/3 - https://src.fedoraproject.org/rpms/extra-cmake-modules/pull-request/2 The change has been offered upstream, but I suppose it will take a while before it is actually landed there. Let me know if you think this needs more discussion before shipping it. (The change is only intended for Fedora 40+ and ELN.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: 16 packages still need a Python 3.12 rebuild, final freeze in 6 days
On 02. 10. 23 15:03, Sandro wrote: On 27-09-2023 11:56, Miro Hrončok wrote: here is the list of packages that still need a Python 3.12 rebuild for Fedora 39+. Not mentioned on the list, but still pending, is the update for spyder. It's not mentioned because it does not need a Python 3.12 rebuild. While still related, this is a bit different situation. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: %pyproject_save_files license handlers
On 19. 08. 23 23:57, Maxwell G wrote: On Sat Aug 19, 2023 at 22:13 +0200, Miro Hrončok wrote: On 19. 08. 23 19:44, Maxwell G wrote: 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? Hey. Alternatively to banning this: what if we make %pyproject_save_files fail without a license? Obviously, that would be a breaking change, so it could be opt-in first. %pyproject_save_files -l ... When used like this, no License-File header would result in an error. We could introduce a reverse flag -L (don't fail without a license), and have a discussion about changing the default later. The guidelines could than say something like: If there is a license file you MUST do one of the following when using %pyproject_save_files: 1) use -l and don't list it in %files explicitly 2) use -L and list it in %files explicitly That way, we ensure the license is packaged (and marked as %license) while not reducing automation. I like -l flag idea, but I don't think we can make it fail by default for the foreseeable future, given the status of PEP 639 and build system adoption. We could use a heuristic (such as a hardcoded list of globs) to match license files in dist-info directories if License-File doesn't exist, but I'm not sure that's the best idea. I'm hesitant about adding a noop -L flag until we actually have a plan/criteria on when to start enforcing -l, but I don't feel strongly. I've drafted the implementation: https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/422 The -l flag asserts at least 1 License-File is present. The -L flag disables the assert (i.e. it does nothing). I was considering the idea that the -L flag would assert no License-File was found, but I don't think that will be that useful. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: 16 packages still need a Python 3.12 rebuild, final freeze in 6 days
On 27. 09. 23 15:58, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Sep 27, 2023 at 11:56:01AM +0200, Miro Hrončok wrote: Hello packagers, here is the list of packages that still need a Python 3.12 rebuild for Fedora 39+. zbyszekpython-igor I retired it now in f39 and rawhide. The first attempt failed halfway because I didn't have a valid token. I repeated the 'fedpkg retire …' command, but I'm not sure if the state got updated correctly. Thanks. The failed token failure is not real. It only fails to disable monitoring. What matters is the dead.package file dist git. See https://pagure.io/fedpkg/issue/505 (opened 6 months ago). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
16 packages still need a Python 3.12 rebuild, final freeze in 6 days
/2154979 Bugzilla ASSIGNED 8 months ago, no update since. Maintainer NEEDINFOed last week. --- Packages fixed in Rawhide with Fedora 39 updates in need of karma: python-box https://bodhi.fedoraproject.org/updates/FEDORA-2023-595f85c4f3 python-click-spinner https://bodhi.fedoraproject.org/updates/FEDORA-2023-39dcc5afea python-elpy https://bodhi.fedoraproject.org/updates/FEDORA-2023-a999e30051 python-nipy https://bodhi.fedoraproject.org/updates/FEDORA-2023-ed0adf8107 python-pvc https://bodhi.fedoraproject.org/updates/FEDORA-2023-05814fcc72 python-pydocstyle https://bodhi.fedoraproject.org/updates/FEDORA-2023-3703495e43 python-sklearn-genetic-opt https://bodhi.fedoraproject.org/updates/FEDORA-2023-d8d9f6376a python-streamlink https://bodhi.fedoraproject.org/updates/FEDORA-2023-0eeb1b6b0e python-uinput https://bodhi.fedoraproject.org/updates/FEDORA-2023-9ba7c6ba53 python-uvicorn https://bodhi.fedoraproject.org/updates/FEDORA-2023-ae19f823c9 python-uvloop https://bodhi.fedoraproject.org/updates/FEDORA-2023-ae19f823c9 python-ZEO https://bodhi.fedoraproject.org/updates/FEDORA-2023-24d588cf46 python-ZODB3 https://bodhi.fedoraproject.org/updates/FEDORA-2023-24d588cf46 Thanks for your help. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Questions about %pyproject_buildrequires
On 13. 09. 23 5:03, Scott Talbert wrote: Hi all, Hi Scott. First, is it possible to use this macro if the pyproject.toml isn't in the root directory of the package? There doesn't seem to be an option to specify a path, so I tried cd'ing into a path and running it, but it seemed to run into an odd error like it was trying to include my directory as a package. You can do this, but you MUST NOT put anything to the standard output. E.g. if you do this: %generate_buildrequires cd subdir %pyproject_buildrequires It'll work properly. However, if you do: %generate_buildrequires cd subdir %pyproject_buildrequires cd - It will generate a dependency on something like /builddir/build/BUILD/pkg-1.2.3 because that is what `cd -` prints to standard output. Same with pushd and popd. The solution is to use >&2 when runnign such commands in %generate_buildrequires. For example: %generate_buildrequires pushd pkg1 >&2 %pyproject_buildrequires popd >&2 pushd pkg2 >&2 %pyproject_buildrequires popd >&2 Second, can %pyproject_buildrequires (and the other %pyproject_ macros) be used multiple times in a package? I have a package that has multiple pyproject.toml files in it (but that's mostly a legacy thing, so I could probably separate them into multiple RPMs). Yes, but %pyproject_insatll SHOULD only be used once (it will install everything, running it multiple times is redundant) and %pyproject_save_files will not work at all. %build pushd pkg1 %pyproject_wheel popd pushd pkg2 %pyproject_wheel popd %install # this will install both wheels: %pyproject_install # we cannot use %%pyproject_save_files here # because mixing files from multiple wheels is not supported -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Looking for a new (possibly better) python-argcomplete maintainer
On 23. 08. 23 13:00, Sandro wrote: On 21-08-2023 13:13, Miro Hrončok wrote: 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? Miro, you are way too young to "be retired". 😜 🤦 I'd be willing to take over maintainership of the package. As always, co-maintainers are welcome. Thanks. I made @gui1ty the main admin a the man bugzilla point of contact for Fedora. On 23. 08. 23 13:39, Christiano Anderson wrote: > If you need a co-maintainer, feel free to invite me. Thanks. Added @canderson9 as a co-admin. On 23. 08. 23 20:47, Maxwell G wrote: > I maintain two of my packages on that list (fedrq and ansible-core), > so I'm happy to co-maintain. Thanks. Added @gotmax23 as a co-admin. Please let me know if I did not figure out your FAS names correctly, neither of you included them in your email, so I had to improvise. There is an open [DO NOT MERGE] PR: https://src.fedoraproject.org/rpms/python-argcomplete/pull-request/19 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: %pyproject_save_files license handlers
On 23. 08. 23 13:17, Sandro wrote:> This might be out of scope, but would it also be possible to have it fail or issue a warning if %pyproject_save_files -l marks a license, but the packager also uses an explicit %license in %files. That would prevent duplication. Unfortunately, the macro have no way of knowing what is included in %files manually, co I am afraid this is not possible to implement. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: %pyproject_save_files license handlers
On 19. 08. 23 19:44, Maxwell G wrote: 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? Hey. Alternatively to banning this: what if we make %pyproject_save_files fail without a license? Obviously, that would be a breaking change, so it could be opt-in first. %pyproject_save_files -l ... When used like this, no License-File header would result in an error. We could introduce a reverse flag -L (don't fail without a license), and have a discussion about changing the default later. The guidelines could than say something like: If there is a license file you MUST do one of the following when using %pyproject_save_files: 1) use -l and don't list it in %files explicitly 2) use -L and list it in %files explicitly That way, we ensure the license is packaged (and marked as %license) while not reducing automation. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Intent to orphan several python packages
On 14. 08. 23 0:17, Mukundan Ragavan wrote: On 8/13/23 16:28, Mukundan Ragavan wrote: 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. python-nbconvert python-nbclient Those are required by notebook and somebody from python-maint will take them if they are orphaned. You can assign them to me (churchyard). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Cython 3 plans
On 20. 07. 23 12:16, Miro Hrončok wrote: scipy cstratak mmuzila nforro orion psimovec tomspur ttomecek Fixed via https://src.fedoraproject.org/rpms/scipy/pull-request/29 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Cython 3 plans
On 20. 07. 23 12:16, Miro Hrončok wrote: On 17. 07. 23 21:09, Miro Hrončok wrote: Hello Pythonistas, apparently, Cython 3.0.0 final was released today. I plan to make it build somehow in https://src.fedoraproject.org/rpms/Cython/pull-request/41 and once it does, I'll update the package in Rawhide, introducing a python(3)-cython0.29 conflicting compact package for those who cannot upgrade yet (like python-lxml). Note that Cython 0.29 was only built without tests during the Python 3.12 bootstrap and I am unsure we will ever be able to enable them again (at least not all of them). We'll get rid of emacs-cython-mode during the transition -- it can be packaged separately by someone else if desired. This is ready to be shipped in: https://src.fedoraproject.org/rpms/Cython/pull-request/41 https://src.fedoraproject.org/rpms/python-cython0.29/pull-request/1 Some packages succeeded in https://copr.fedorainfracloud.org/coprs/g/python/cython0.29/ but failed in https://copr.fedorainfracloud.org/coprs/g/python/cython3/ Unless the failure was transient, they will need to pin the build dependency on python3dist(cython) < 3~~. Maintainers by package: ... numpy cstratak limb orion rdieter tomspur ttomecek https://src.fedoraproject.org/rpms/numpy/pull-request/35 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Retiring python-pytest-flake8
On 27. 07. 23 18:26, Michel Alexandre Salim wrote:
⬢ [fedora-toolbox:38] ❯ rpmdistro-repoquery fedora rawhide
--enablerepo=fedora-source --whatrequires python-pytest-flake8
Always use the actual binary package name for queries like this, as only the
actual package name will show all dependencies that happen to require a
differetn virtual provide:
$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-pytest-flake8
cvise-0:2.4.0-3.fc36.src
python-cssutils-0:2.6.0-2.fc38.src
python-nashpy-0:0.0.37-1.fc39.src
python-pyunicorn-0:0.6.1-12.fc38.src
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Cython 3 plans
On 20. 07. 23 12:16, Miro Hrončok wrote: On 17. 07. 23 21:09, Miro Hrončok wrote: Hello Pythonistas, apparently, Cython 3.0.0 final was released today. I plan to make it build somehow in https://src.fedoraproject.org/rpms/Cython/pull-request/41 and once it does, I'll update the package in Rawhide, introducing a python(3)-cython0.29 conflicting compact package for those who cannot upgrade yet (like python-lxml). Note that Cython 0.29 was only built without tests during the Python 3.12 bootstrap and I am unsure we will ever be able to enable them again (at least not all of them). We'll get rid of emacs-cython-mode during the transition -- it can be packaged separately by someone else if desired. This is ready to be shipped in: https://src.fedoraproject.org/rpms/Cython/pull-request/41 https://src.fedoraproject.org/rpms/python-cython0.29/pull-request/1 Some packages succeeded in https://copr.fedorainfracloud.org/coprs/g/python/cython0.29/ but failed in https://copr.fedorainfracloud.org/coprs/g/python/cython3/ Unless the failure was transient, they will need to pin the build dependency on python3dist(cython) < 3~~. Maintainers by package: ... PyYAML jeckersb https://src.fedoraproject.org/rpms/PyYAML/pull-request/9 ... python-lxml cstratak fale lbalhar mizdebsk https://src.fedoraproject.org/rpms/python-lxml/pull-request/29 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Cython 3 plans
On 20. 07. 23 12:16, Miro Hrončok wrote: python-rapidfuzz thrnciar troycurtisjr See https://src.fedoraproject.org/rpms/python-rapidfuzz/pull-request/2 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Cython 3 plans
On 17. 07. 23 21:09, Miro Hrončok wrote: Hello Pythonistas, apparently, Cython 3.0.0 final was released today. I plan to make it build somehow in https://src.fedoraproject.org/rpms/Cython/pull-request/41 and once it does, I'll update the package in Rawhide, introducing a python(3)-cython0.29 conflicting compact package for those who cannot upgrade yet (like python-lxml). Note that Cython 0.29 was only built without tests during the Python 3.12 bootstrap and I am unsure we will ever be able to enable them again (at least not all of them). We'll get rid of emacs-cython-mode during the transition -- it can be packaged separately by someone else if desired. This is ready to be shipped in: https://src.fedoraproject.org/rpms/Cython/pull-request/41 https://src.fedoraproject.org/rpms/python-cython0.29/pull-request/1 Some packages succeeded in https://copr.fedorainfracloud.org/coprs/g/python/cython0.29/ but failed in https://copr.fedorainfracloud.org/coprs/g/python/cython3/ Unless the failure was transient, they will need to pin the build dependency on python3dist(cython) < 3~~. Maintainers by package: MUSICankursinha PyYAML jeckersb cantera fuller sic h5py orion stevetraylen terjeros libarrow kkeithle libfreenect jkastner kathenas kwizart rmattes libgpuarray orphan mlpack fed500 rcurtin mpi4py limb tomspur numpycstratak limb orion rdieter tomspur ttomecek petscsagitter pygame jskarvad limb sergiomb pyliblo fab python-blosc2zbyszek python-calcephpy mattia python-cftimeorion python-comprefformusic python-cyipopt music python-cysignals pcpa python-cytoolz orion python-djvulibre aekoroglu python-editdistance-s limb python-ezdxf music python-fastavro ankursinha python-gbinder aleasto python-giacpysagitter python-gssapisimo python-healpylupinix python-hidapijonny python-imagecodecs orion python-indexed_gzip ankursinha python-jnius raphgro python-kmod grover mlombard python-llfusedfateyev maci python-lxml cstratak fale lbalhar mizdebsk python-oracledb stevetraylen python-orderedsetvtrefny python-pari-jupyter jjames python-peeweecarlwgeorge cstratak vkrizan python-pplpy jjames python-pyclipper athoscr python-pyedflib iztokf python-pysam davidsch python-pyspike ankursinha python-rapidfuzz thrnciar troycurtisjr python-rtmidifab python-smartcols kalev python-statsmodels sergiopr python-tablesjonathanspw zbyszek python-uamqp mhayden rdma-coredledford honli jwilson kheib michich rust-cbindgendecathorpe scipycstratak mmuzila nforro orion psimovec tomspur ttomecek setools alexl caolanm dwalsh mbarnes pcmoore plautrba rhughes rstrode vmojzis urh jskarvad vapoursynth slaanesh Packages by maintainer: aekoroglu python-djvulibre aleastopython-gbinder alexl setools ankursinha MUSIC python-fastavro python-indexed_gzip python-pyspike athoscrpython-pyclipper caolanmsetools carlwgeorge python-peewee cstratak numpy python-lxml python-peewee scipy davidsch python-pysam decathorpe rust-cbindgen dfateyev python-llfuse dledford rdma-core dwalsh setools fabpyliblo python-rtmidi fale python-lxml fed500 mlpack fuller cantera grover python-kmod honli rdma-core iztokf python-pyedflib jeckersb PyYAML jjames python-pari-jupyter python-pplpy jkastner libfreenect jonathanspw python-tables jonny python-hidapi jskarvad pygame urh jwilsonrdma-core kalev python-smartcols kathenas libfreenect kheib rdma-core kkeithle libarrow kwizartlibfreenect lbalharpython-lxml limb mpi4py numpy pygame python-editdistance-s lupinixpython-healpy maci python-llfuse mattia python-calcephpy mbarnessetools mhaydenpython-uamqp michichrdma-core mizdebsk python-lxml mlombard python-kmod mmuzilascipy music python-compreffor python-cyipopt python-ezdxf nforro scipy orion h5py numpy python-cftime python-cytoolz python-imagecodecs scipy orphan libgpuarray pcmooresetools pcpa python-cysignals plautrba setools psimovec scipy raphgropython-jnius rcurtinmlpack rdieternumpy rhughessetools rmatteslibfreenect rstrodesetools sagitter petsc python-giacpy sergiomb pygame sergiopr python-statsmodels siccantera simo python-gssapi slaanesh vapoursynth stevetraylen h5py python-oracledb terjeros h5py thrnciar python-rapidfuzz tomspurmpi4py numpy scipy troycurtisjr python-rapidfuzz ttomecek numpy scipy vkrizanpython-peewee vmojzissetools vtrefnypython-order
Cython 3 plans
Hello Pythonistas, apparently, Cython 3.0.0 final was released today. I plan to make it build somehow in https://src.fedoraproject.org/rpms/Cython/pull-request/41 and once it does, I'll update the package in Rawhide, introducing a python(3)-cython0.29 conflicting compact package for those who cannot upgrade yet (like python-lxml). Note that Cython 0.29 was only built without tests during the Python 3.12 bootstrap and I am unsure we will ever be able to enable them again (at least not all of them). We'll get rid of emacs-cython-mode during the transition -- it can be packaged separately by someone else if desired. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Py3.12: vit -> urwid -> undefined symbol: PyUnicode_AS_UNICODE
On 06. 07. 23 11:21, Ankur Sinha wrote:
Hi folks,
While looking into the vit FTI bug[1], I ran into this error in the
test:
==
ERROR: vit (unittest.loader._FailedTest.vit)
--
ImportError: Failed to import test module: vit
Traceback (most recent call last):
File "/usr/lib64/python3.12/unittest/loader.py", line 415, in _find_test_path
package = self._get_module_from_name(name)
File "/usr/lib64/python3.12/unittest/loader.py", line 325, in
_get_module_from_name
__import__(name)
File "/builddir/build/BUILD/vit-2.3.0/vit/__init__.py", line 2, in
from .application import Application
File "/builddir/build/BUILD/vit-2.3.0/vit/application.py", line 19, in
from vit.formatter_base import FormatterBase
File "/builddir/build/BUILD/vit-2.3.0/vit/formatter_base.py", line 8, in
from vit import util
File "/builddir/build/BUILD/vit-2.3.0/vit/util.py", line 7, in
from urwid.str_util import calc_width
ImportError:
/usr/lib64/python3.12/site-packages/urwid/str_util.cpython-312-x86_64-linux-gnu.so:
undefined symbol: PyUnicode_AS_UNICODE
A web search brought me here:
https://github.com/cython/cython/issues/5149
How would we fix this? Is this something that needs fixing in urwid?
I still see PyUnicode_AS_UNICODE used there:
https://github.com/search?q=repo%3Aurwid%2Furwid%20PyUnicode_AS_UNICODE&type=code
(and no issues filed about it yet).
This is https://peps.python.org/pep-0623/#python-3-12
I don't know what is the proper replacement. Either way, this needs to be fixed
in python-urwid. It has tests ignored out, so the problem was masked away. It
could at least use an import check.
It has this in the build.log:
gcc ... -fPIC -I/usr/include/python3.12 -c source/str_util.c -o
build/temp.linux-x86_64-cpython-312/source/str_util.o
source/str_util.c: In function ‘Py_IsWideChar’:
source/str_util.c:484:16: warning: implicit declaration of function
‘PyUnicode_AS_UNICODE’; did you mean ‘PyUnicode_AsUCS4’?
[-Wimplicit-function-declaration]
484 | ustr = PyUnicode_AS_UNICODE(text);
|^~~~
|PyUnicode_AsUCS4
source/str_util.c:484:14: warning: assignment to ‘Py_UNICODE *’ {aka ‘int *’}
from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
484 | ustr = PyUnicode_AS_UNICODE(text);
| ^
source/str_util.c: In function ‘Py_CalcWidth’:
source/str_util.c:663:14: warning: assignment to ‘Py_UNICODE *’ {aka ‘int *’}
from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
663 | ustr = PyUnicode_AS_UNICODE(text);
| ^
source/str_util.c: In function ‘Py_CalcTextPos’:
source/str_util.c:749:14: warning: assignment to ‘Py_UNICODE *’ {aka ‘int *’}
from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
749 | ustr = PyUnicode_AS_UNICODE(text);
| ^
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)
On 05. 07. 23 7:54, Miro Hrončok wrote: On 04. 07. 23 16:51, Tomáš Hrnčiar wrote: Hello. As you might already know, we have recently conducted a Python 3.12mass rebuild in aside tag. We plan to ask releng to merge it today, despite several builds not succeeding. This has not happened yet, see https://pagure.io/releng/issue/11451 for progress update. The side tag has been merged. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)
On 04. 07. 23 16:51, Tomáš Hrnčiar wrote: Hello. As you might already know, we have recently conducted a Python 3.12mass rebuild in aside tag. We plan to ask releng to merge it today, despite several builds not succeeding. This has not happened yet, see https://pagure.io/releng/issue/11451 for progress update. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Python 3.12 side tag merging today (and what to do)
On 04. 07. 23 20:11, Steven A. Falco wrote: On 7/4/23 10:51 AM, Tomáš Hrnčiar wrote: ## How to run things locally? You can use mock. Make sure to: 1. Clear all caches first: $ mock -r fedora-rawhide-x86_64--scrub=all 2. Use the Koji repo: $ mock -r fedora-rawhide-x86_64 --enablerepo=local ... That doesn't appear correct. At least I still get 3.11 when I try. I assume I need to refer to the side tag instead. This will only work once the side tag is actually merged. I have requested the merge from releng but I cannot do it myself. Also there is a typo - there needs to be a space between fedora-rawhide-x86_64 and --scrub=all :-) Indeed. Thanks for spotting this and sorry about that. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 27. 06. 23 21:37, Maxwell G wrote: If your package is failing with ModuleNotFoundError: No module named 'imp', this is happening because Python 3.12 removed the long deprecated imp module. As a stopgap measure, you can BuildRequire python3-zombie-imp package, which allows you to import the imp module even on Python 3.12. We strongly recommend talking to upstream and encouraging them to migrate to importlib instead. The package has `Provides: deprecated()` so that cannot be done without violating policy. The idea is that packages that already use (deprecated) imp can migrate to this as a stop gap measure. But no new packages should depend on this. We could *not deprecate* it instead and submit a change proposal to deprecate it later, but that seems rather useless. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 18. 06. 23 15:17, Barry Scott wrote: On 17 Jun 2023, at 10:50, Miro Hrončok 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 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 ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 13. 06. 23 14:02, Tomas Hrnciar wrote: 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 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter 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 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=-build_id&inherited=0 <https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f39-python&order=-build_id&inherited=0> 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. Hey folks, apologies if you have missed our announcement, but I'd like to ask you not to build packages in rawhide if they have received a "Rebuilt for Python 3.12" commit. For details, see the announcement quoted above. The following packages have been rebuilt in rawhide after we have rebuilt them in the f39-python side tag and so I bumped them again and built them again in f39-python: legendary python-boto3 tracer Please avoid further rawhide builds of them until the side tag is merged. Thanks and sorry for the trouble. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 13. 06. 23 14:02, Tomas Hrnciar wrote: 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 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter 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 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=-build_id&inherited=0 <https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f39-python&order=-build_id&inherited=0> 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. Hey folks, apologies if you have missed our announcement, but I'd like to ask you not to build packages in rawhide if they have received a "Rebuilt for Python 3.12" commit. For details, see the announcement quoted above. The following packages have been rebuilt in rawhide after we have rebuilt them in the f39-python side tag and I will now bump them again and build them again in f39-python: python-google-api-core python-radexreader Please avoid further rawhide builds of them until the side tag is merged. Thanks and sorry for the trouble. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
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 ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 16. 06. 23 9:57, Bastien Nocera wrote: On Fri, 16 Jun 2023 at 09:48, Miro Hrončok <mailto:mhron...@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 ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 16. 06. 23 9:41, Miro Hrončok wrote: The following packages were built in rawhide after they were built in out Python 3.12 side tag (f39-python): ... python-cerberus I believe this also wasn't built after 3.12 rebuild, but the rawhide version is 0-1.3.4-1.fc38, which is > 0-1.3.2-3.fc39. The dist-git history goes: 1.3.1 -> 1.3.2 -> 1.3.4 -> 1.3.3 -> 1.3.2 https://src.fedoraproject.org/rpms/python-cerberus/commits/rawhide Not sure how to fix this properly without stepping on the maintainers' toes. I've opened https://src.fedoraproject.org/rpms/python-cerberus/pull-request/2 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 13. 06. 23 14:02, Tomas Hrnciar wrote: 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 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter 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 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=-build_id&inherited=0 <https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f39-python&order=-build_id&inherited=0> 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. Hey folks, apologies if you have missed our announcement, but I'd like to ask you not to build packages in rawhide if they have received a "Rebuilt for Python 3.12" commit. For details, see the announcement quoted above. The following packages have been rebuilt in rawhide after we have rebuilt them in the f39-python side tag and I will now bump them again and build them again in f39-python: clang lldb Please avoid further rawhide builds of them until the side tag is merged. Thanks and sorry for the trouble. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
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 ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 16. 06. 23 8:49, Miro Hrončok wrote: On 13. 06. 23 14:02, Tomas Hrnciar wrote: 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 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter 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 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=-build_id&inherited=0 <https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f39-python&order=-build_id&inherited=0> 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. The following packages were built in rawhide after they were built in out Python 3.12 side tag (f39-python): ... python-cerberus I believe this also wasn't built after 3.12 rebuild, but the rawhide version is 0-1.3.4-1.fc38, which is > 0-1.3.2-3.fc39. The dist-git history goes: 1.3.1 -> 1.3.2 -> 1.3.4 -> 1.3.3 -> 1.3.2 https://src.fedoraproject.org/rpms/python-cerberus/commits/rawhide Not sure how to fix this properly without stepping on the maintainers' toes. Please, don't do that. I will now rebuild them in the side tag again. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 16. 06. 23 8:49, Miro Hrončok wrote: On 13. 06. 23 14:02, Tomas Hrnciar wrote: 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 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter 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 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=-build_id&inherited=0 <https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f39-python&order=-build_id&inherited=0> 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. The following packages were built in rawhide after they were built in out Python 3.12 side tag (f39-python): ... python-hpack This one wasn't actually rebuilt after that, but for some reason, f39-build has higher version from an older build: python-hpack 0-4.0.0-7.fc37 > 0-4.0.0-4.fc39 The package was converted to rpmautospec and back and does not sort correctly. I'll bump the release to 8. Please, don't do that. I will now rebuild them in the side tag again. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 13. 06. 23 14:02, Tomas Hrnciar wrote: 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 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter 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 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=-build_id&inherited=0 <https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f39-python&order=-build_id&inherited=0> 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. The following packages were built in rawhide after they were built in out Python 3.12 side tag (f39-python): codespell devscripts iscsi-initiator-utils libxc miniupnpc petsc python-apypie python-bitarray python-boto3 python-cerberus python-cloudflare python-hpack python-pyudev Please, don't do that. I will now rebuild them in the side tag again. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week
On 13. 06. 23 14:02, Tomas Hrnciar wrote: 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 <https://fedoraproject.org/wiki/Changes/Python3.12> We anticipate starting this rebuildsometimethis week. If you see a "Rebuilt for Python 3.12" (or similar) commit in your package, please don't rebuild it in regular rawhideor another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build apackageafter 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 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=-build_id&inherited=0 <https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f39-python&order=-build_id&inherited=0> 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. FTR it has started. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: nest: python package still setup.py; also needs to be built for MPI
On 12. 06. 23 16:04, Ankur Sinha wrote: 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? This is currently not possible. Unfortunately, support for this would require somebody else than me to drive it. (If you just need to install the same files in multiple locations, you can cp -a them around after %pyproject_install.) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Question regarding setuptools automatic discovery (pyproject.toml)
On 04. 06. 23 1:54, Sandro wrote: Hi, Hey. 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. First of all, upstream wheel downloaded from https://pypi.org/project/palettable/3.3.3/#files includes build, docs and test as well. I think the elicit exclude configured at https://github.com/jiffyclub/palettable/blob/v3.3.3/pyproject.toml#L35 migth override the DEFAULT_EXCLUDE value. I don't know how tool.setuptools.packages.find.exclude behaves, but I have seen this behavior with pytest, where the default was to exclude a bunch of directories including ".*", but projects that set their own excludes (without ".*") suddenly started to collect tests from our .pyproject-* folders. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: python macros inconsistency between Fedora and EPEL9
On 03. 06. 23 13:29, Mattia Verga wrote: 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. It's not in epel because it is in RHEL. 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? I have no idea. What makes you suspect this problem is related to *Python* macros at all? %ctest is defined in /usr/lib/rpm/macros.d/macros.cmake which is shipped by cmake-rpm-macros, a subpackage of cmake. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
pyproject-rpm-macros 1.9.0: Support for passing config_settings to the build backend
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] ...
...
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
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Guidance for a python package update
On 30. 05. 23 15:13, Troy Curtis Jr wrote: Please, attempt to change the dependents. Since the requires generally come from the package metadata itself, does this mean changing upstream for each dependency? Or just patch for our Fedora packages? Presumably they could be patched and then built together with the updated name, I presume this is where side tags come in to play? (It'll be a new experience for me!) I'd send a PR upstream and use that as a patch for Fedora. Using side tags to ship this is a good idea, yes. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Guidance for a python package update
Hi Troy.
On 29. 05. 23 18:01, Troy Curtis Jr wrote:
I'm currently working on the update for python-Levenshtein [1] and I have a
question about the best way to proceed.
In the intervening time since the last release we have packaged, a new
maintainer has taken over maintenance, and built the updates around a stack of
other packages (rapidfuzz-cpp, python-rapidfuzz, scikit-build, etc). Now that
all these dependencies are available I can look to actually do the update. As
part of the updates, the current maintainer has deprecated the original pypi
name of "python-Levenshtein" in favor of the more typical name without the
"python-" prefix. He is continuing to maintain the "python-Levenshtein" pypi
package for compatibility, but now it is just an empty package which defines
"Levenshtein" as a dependency [2]. This means the upstream for the Fedora
python-Levenshtein package must point to the new Levenshtein package in order
to get the actual package contents. However, this means the metadata for the
package indicates the name "Levenshtein" which translate to a provide for
"python3.11dist(levenshtein)", but that is different than the currently
provided "python3.11dist(python-levenshtein)", which current dependencies
require. One option would be to simply manually add a
"python3.11dist(python-levenshtein)" provide, but it seems this seems
specifically prohibited in the Python packaging guidelines [3].
And there is a reason. If the package "claimed" to be
python3dist(python-levenshtein), yet the Python metadata would say it's
levenshtein, all automation that generates requirements for
python3dist(python-levenshtein) would happily accept it, but fail on Python
level. For example, the %pyproject_buildrequires macro, when it encounters an
unmet dependency on levenshtein on the Python level, prints out
python3dist(levenshtein) and restarts for dnf to take over. dnf then installs
the package but the macro still does not see the package on Python level, so it
prints it out again and restarts...
I think there are 2 options:
- Manually provide the legacy name outside of the python package meta-data
Please don't.
- Rebuild all users of the provide to use the new name
It's not that many:
$ repoquery -q --repo=rawhide{,-source} --whatrequires
'python3.11dist(python-levenshtein)' --whatrequires
'python3dist(python-levenshtein)'
paperwork-0:2.1.2-2.fc38.src
python-paperwork-backend-0:2.1.2-2.fc38.src
python3-paperwork-0:2.1.2-2.fc38.noarch
python3-paperwork-backend-0:2.1.2-2.fc38.noarch
The main downside to the second approach is that nothing would provide the
python-Levenshtein name, which is still present and usable via pypi and
perfectly compatible with the current library implementation.
But do we need it in Fedora?
If you really need this, you could insert a second dist-info metadata to the
package, so it would ship:
%{python_sitearch}/...actual content here...
%{python_sitearch}/Levenshtein-0.21.0.dist-info/
%{python_sitelib}/python_Levenshtein-0.21.0.dist-info/
That way, it provides both names on Python and RPM level both.
But I consider that an overkill.
So what is the appropriate course of action here?
Please, attempt to change the dependents.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [EPEL-devel] Re: python3.11-rpm to EPEL 9
On 16. 05. 23 15:44, Maxwell G wrote:
On Tue May 16, 2023 at 11:04 +0200, Miro Hrončok wrote:
On 15. 05. 23 16:49, Maxwell G wrote:
On Mon May 15, 2023 at 12:14 +0200, Miro Hrončok wrote:
Hello,
I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next.
See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4.
Cool!
I decided to reuse the python3-rpm component (currently epel7 only). Let me
know if I should not.
Are we able to build for multiple Python versions out of the same
specfile?
It's possible, but it's not nice.
In principle, this works:
%build
%define py3x_build() %{global python3_pkgversion %1}%py3_build
%py3x_build 39
%py3x_build 3.11
%install
%define py3x_install() %{global python3_pkgversion %1}%py3_install
%py3x_install 39
%py3x_install 3.11
But with a project like RPM, we might need to run configure multiple times as
well and create separate working directories. Will need to check.
Yeah, that could work,
but I'd change %{global python3_pkgversion %1} to
%{define python3_pkgversion %1} in the py3x_* macro definitions so you
only change the definition of %python3_pkgversion within those macros'
scopes.
Unless there's some other way to work around this, I'd use a
python3.11-rpm or python3.11-rpm-epel component like we've been doing
for the other alt python stacks in RHEL 8.
I consider the "not nice" way easier, as it will only require to keep one
package synced with c8s rpm, and not many. Will try to hack it up and show how
it looks like.
I tend to agree. Syncing packages with RHEL and CentOS Stream is
difficult and tedious so better to limit the amount of times you have to
do it. Carl's new EPEL 10 proposal will hopefully with this.
OK, here's an EPEL 8 demo with multiple Python versions:
https://src.fedoraproject.org/rpms/python3-rpm/pull-request/5
(I am not sure if Python 3.11 is available in the EPEL 8 buildroot already, but
if it is not, we can probably just wait a bit instead of building this in EPEL
8 Next first.)
Unfortunately the trick with %{global python3_pkgversion %1} inside a %define
seemed to work on Fedora 37, but RHEL 8 did not like it (especially with
multiline macros) an I was unable to make it work. Instead, I kept %global'ing
%python3_pkgversion back and forth.
It is not as bad as expected actually, this version of RPM still supports
building and installing the Python bindings via distutils, so I only needed to
run configure once.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
pyproject-rpm-macros 1.8.0: self-referential extras, %{pyproject_build_lib} deprecated
Hello Pythonistas,
I've built pyproject-rpm-macros-1.8.0-1.fc39 in Rawhide and updates are
available for older Fedoras. Later on I plan to sync this to c9s as well.
https://bodhi.fedoraproject.org/updates/pyproject-rpm-macros
The release brings a bugfix/enhancement (depending on how you look at it) and a
deprecation.
## %pyproject_buildrequires now supports self-referential extras requirements
That is, if you package e.g. attrs and use:
%pyproject_buildrequires -x tests
It correctly handles the requirement on attrs[tests-no-zope] as defined here:
https://github.com/python-attrs/attrs/blob/23.1.0/pyproject.toml#L45
When a self-referential dependency on extras is found, the required extra is
added to the list of desired extras, and all the previously discarded "alien"
requirements are reevaluated using the new extras list.
Example use: https://src.fedoraproject.org/rpms/python-fiona/pull-request/2
## The provisional %{pyproject_build_lib} macro was deprecated
There is no scheduled removal, but it may break entirely in the future.
See
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/HMLOPAU3RZLXD4BOJHTIPKI3I4U6U7OE/
for motivation.
Packagers are encouraged to use
$PWD/build/lib.%{python3_platform}-cpython-%{python3_version_nodots} instead if
they need to (works on all current Fedoras but not on RHEL 9's Python 3.9).
The following Fedora Rawhide packages use it:
asv
buku
ocrmypdf
pytest
python-Automat
python-constantly
python-cppy
python-cypari2
python-cysignals
python-elasticsearch
python-graphviz
python-hyperframe
python-hyperlink
python-h2
python-libdiscid
python-mistune
python-mplcursors
python-nb2plots
python-networkx
python-nipy
python-numcodecs
python-opentracing
python-pbr
python-persistent
python-pikepdf
python-pplpy
python-primecountpy
python-priority
python-pybtex
python-pyedflib
python-pytest-regressions
python-service-identity
python-simplejson
python-stestr
python-transforms3d
python-twisted
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [EPEL-devel] python3.11-rpm to EPEL 9
On 15. 05. 23 16:49, Maxwell G wrote:
On Mon May 15, 2023 at 12:14 +0200, Miro Hrončok wrote:
Hello,
I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next.
See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4.
Cool!
I decided to reuse the python3-rpm component (currently epel7 only). Let me
know if I should not.
Are we able to build for multiple Python versions out of the same
specfile?
It's possible, but it's not nice.
In principle, this works:
%build
%define py3x_build() %{global python3_pkgversion %1}%py3_build
%py3x_build 39
%py3x_build 3.11
%install
%define py3x_install() %{global python3_pkgversion %1}%py3_install
%py3x_install 39
%py3x_install 3.11
But with a project like RPM, we might need to run configure multiple times as
well and create separate working directories. Will need to check.
That PR has:
```
+ # We'll build python3.11-rpm only for now
+ # Once a new Python version is added,
+ # the spec will need to change to support multiple Pythons anyway
+ %global python3_pkgversion 3.11
```
but I thought we got rid of the %py3_other_* stuff that allowed building
for multiple Python versions out of the same specfile.
We did.
Unless there's some other way to work around this, I'd use a
python3.11-rpm or python3.11-rpm-epel component like we've been doing
for the other alt python stacks in RHEL 8.
I consider the "not nice" way easier, as it will only require to keep one
package synced with c8s rpm, and not many. Will try to hack it up and show how
it looks like.
If there is a significant demand, I can try add this (and python39-rpm) to EPEL
8 as well.
As I said on IRC, I'd like that for fedrq.
Ack.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
python3.11-rpm to EPEL 9
Hello, I'm working on adding python3.11-rpm to EPEL 9 and EPEL 9 Next. See https://src.fedoraproject.org/rpms/python3-rpm/pull-request/3 and 4. I decided to reuse the python3-rpm component (currently epel7 only). Let me know if I should not. If there is a significant demand, I can try add this (and python39-rpm) to EPEL 8 as well. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
How to drop 32bit support from the scientific Python stack
Hello folks, Couple months ago, we discussed with @psimovec if it's possible to ExcludeArch i686 from scipy. This Python discussion brought the topic back: https://discuss.python.org/t/dropping-32-bit-packages/5476/9 I've tried to see how many packages would be affected and the short answer is: all of them, unless we break the dependency chains somewhere. There are many deep transitive build dependency chains on scipy, but the perhaps most interesting one is: (everything) <- rpm <- rust-rpm-sequoia <- rust-packaging <- pytest <- python-hypothesis <- python-pandas <- scipy Another interesting fact is that the majority of the dependency chains I found traverses through a path of noarch Python packages (such as pytest). If scipy drops i686 we would need to conditionalize the test-related BuildRequires of such noarch packages -- unfortunately that would mean that based on randomness (noarch packages are built on random archotcture), not all tests would always run and we could potentially ship packages that are broken / untested properly. And if we don't conditionalize the dependencies, the packages would randomly fail to build. An alternative is to make all the related packages archful with noarch python3-xxx subpackages -- which would be quite tedious and wasteful resource-wise. The best way forward for this use case (and many others that will show up sooner or later) would be to stop building noarch packages on i686. That way, only archful packages that (Build)Require scipy would need to be changed. Would that be possible? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
