Re: %pyproject_save_files for packages without Python modules
On 30-10-2024 12:47, Miro Hrončok via python-devel wrote:
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.
I prefer the module glob being mandatory as it is now. Allowing for the
module glob to be optional suggests to me the macro will automatically
detect what it needs to save. This is not the case and it will lead to a
mix of spec file styles where some packagers will use the current syntax
with a macro populated %files section and others amending the %files
section when they actually should/could use the correct macro syntax.
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.
Painful to read indeed. Easily overlooked, more difficult to understand.
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.
I haven't had to use +auto yet. Seeing that the no modules case is
rather special as well, I could live with it being +nomodules. Though,
linguistically it's a bit weird...
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.
I'm most in favor of this syntax. It aligns with other pyproject macros
as well as other options passed to %pyproject_save_files. It also makes
it explicit to the reader that the macro behavior is being "tweaked".
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.
It's weird in that %{pyproject_files} is explicitly tied to the use of
%pyproject_save_files in the documentation.
-- Sandro
--
___
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: Let's retire pytest7 and pluggy1.3?
On 31-01-2025 18:17, Miro Hrončok via python-devel wrote: When dealing with python-nose removals I noticed the python-pytest7 package sues nose in tests. Those tests could be easily skipped, but I wonder if it isn't time to get rid of pytest7 (and pluggy1.3). How about making this part of the python-nose retirement change proposal? At some point, pytest offered some functionality to run nose tests [1]. Obviously, projects still relying on nose should long have migrated to pytest proper and are probably no longer being looked after themselves. With Fedora having migrated to pytest 8 [2], which no longer supports running nose tests, it kind of makes sense to drop both packages simultaneously. [1] https://docs.pytest.org/en/7.4.x/how-to/nose.html [2] https://fedoraproject.org/wiki/Changes/Pytest_8 -- Sandro -- ___ 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: Replace python-crypto with python-pycryptodome in Fedora?
On 06-01-2025 20:48, W. Michael Petullo via python-devel wrote: In light of the lack of maintenance, should we offer a formal change proposal to replace python-crypto with python-pycryptodome in Fedora 42 or beyond? Following the discussion on the devel list [1], I think replacing python-crypto with python-cryptodome is the way forward. [1] https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/VYJ7CIR7GMLUNNXYYZAIIMG3POBIVQCB/ -- Sandro -- ___ 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: python3-testrepository and python3-pbr
On 29-07-2025 05:02, Maxwell G via python-devel wrote: python-testrepository @epel-packagers-sig, dcavalca, 2 weeks ago python3-pbr depends on this package which several other Python packages (especially those in the openstack ecosystem) use. If python- testrepository is retired (i.e., if nobody picks it up within the next 4 weeks), 99 Python packages will start failing to build. It is a test dependency only. I've submitted a PR for python-pbr [1] dropping it. It only affects one test. [1] https://src.fedoraproject.org/rpms/python-pbr/pull-request/15 -- Sandro -- ___ 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
