Re: A tool to convert Python packages to pyproject RPM macros

[Miro Hrončok via python-devel]

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

[Miro Hrončok via python-devel]

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: How to pass arbritary options in SPEC file for python build

[Miro Hrončok via python-devel]

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

Re: How to pass arbritary options in SPEC file for python build

[Miro Hrončok via python-devel]

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

%pyproject_save_files for packages without Python modules

[Miro Hrončok via python-devel]

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: Should I join python-packagers?

[Miro Hrončok via python-devel]

On 04. 11. 24 21:25, Blaise Pabon via python-packagers-sig wrote:
I think I would like to join python packagers... unless the group is only 
concerned with packaging the cpython language for Fedora.


Hello Blaise,

first of all, python-packagers-...@lists.fedoraproject.org is not for 
communication, it is for Bugzilla emails.


See https://fedoraproject.org/wiki/SIGs/Python#Communicate

The python-packagers-sig group is not only concerned with  packaging the 
cpython interpreter.


It is described in 
https://fedoraproject.org/wiki/SIGs/Python#Python_SIG_FAS_group

According to https://accounts.fedoraproject.org/group/python-packagers-sig/ 
 I should 
contact one of the group sponsors, but I don't know how they will respond to 
some random guy who is not yet even a proven packager.


Being provenpackager is not a prerequisite for joining the group, it's the 
other way around really, this group is like "provenpackagers for packages 
co-maintained by the group".


Demonstrating a deeper understanding of Python packaging in Fedora is necessary.

Why do you want to join in the first place?

--
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

[Miro Hrončok via python-devel]

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

[Miro Hrončok via python-devel]

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

Re: Loudly deprecating setup.py-based macros %py3_build %py3_install

[Miro Hrončok via python-devel]

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: How to pass arbritary options in SPEC file for python build

[Miro Hrončok via python-devel]

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

pyproject-rpm-macros 1.15/1.16: %pyproject_buildrequires -p and -g

[Miro Hrončok via python-devel]

Hey Pythonistas,

%pyproject_buildrequires has gained 2 new flags: -p and -g

-p reads runtime dependencies (and extras given via -x or read from tox 
configuration) directly from the pyproject.toml [project] table. This is useful 
for backends that do not implement the optional 
prepare_metadata_for_build_wheel PEP 517 hook. Ideally, this should replace all 
usages of the provisional -w flag (and we are filing Pull Requests for such 
cases). This was added to pyproject-rpm-macros 1.15 by Karolina Surma.



-g generates BuildRequires specified via given dependency group(s) from the 
pyproject.toml [dependency-groups] table. See PEP 735:

  https://peps.python.org/pep-0735/
If you use %pyproject_buildrequires with tox (-t/-e) and tox is configured to 
use a dependency group, this will work as well with tox 4.23+.

This was added to pyproject-rpm-macros 1.16 by me.

The new 1.16 version of pyproject-rpm-macros is available in all Fedoras and is 
on its way to c10s and c9s.


tox 4.23 is currently available in Rawhide + updates-testing on stable Fedoras. 
I will also update it in EPEL 10 soon (it waits for pyproject-rpm-macros 1.16 
in c10s). EPEL 9 is stuck with tox 3 for the time being (likely forever).


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: How to package Python bindings for Tree-sitter parsers?

[Miro Hrončok via python-devel]

On 26. 11. 24 14:52, Peter Oliver via python-devel wrote:
TL;DR: Should Rust bindings for Tree-sitter parsers be packaged independently 
(using the usual Python packaging process), or should they be a subpackage of 
the main Tree-sitter parser package (effectively giving us Python bindings for 
free)?  Do we even want Python bindings for Tree-sitter parsers in the first 
place?


Here’s the long version.  Tree-sitter is a library for writing parsers for 
source code, for use in, for example, syntax highlighters and text editors. 
Nearly 500 different parsers are available separately (https://github.com/tree- 
sitter/tree-sitter/wiki/List-of-parsers).  However, we only have one of them 
packaged for Fedora so far.


Spec files for Tree-sitter parsers will all be very similar to each other, and 
could probably be generated by simple-minded RPM macros (a draft of which are 
at https://src.fedoraproject.org/rpms/tree-sitter/pull-request/1#request_diff).


Official bindings are available for using the parsers from a number of 
languages, including Python.  The Tree-sitter project has tooling to 
automatically generate these bindings, which are committed to the Git 
repository of each parser.  On release, the bindings are uploaded to the native 
repository for each language (i.e., pypi.org for Python).


This gives us a choice:

- We could treat Python bindings for Tree-sitter as any other Python project, 
with the souce fetched from pypi.org.  If someone wanted them, they would need 
to package them in the usual Python way.


- We could package Python bindings for Tree-sitter as a subpackage of the 
package that builds the parser as a C library, with the source fetched from 
github.com.  We would have Python bindings for every Tree-sitter parser 
packaged for Fedora.  The Tree-sitter-specific RPM macros used in these 
packages may need tweaking in future to keep up with any changes to the Python 
packaging guidelines.




Or we could not package them at all unless something we care about depends on 
them.


--
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: pyproject-rpm-macros 1.15/1.16: %pyproject_buildrequires -p and -g

[Miro Hrončok via python-devel]

On 15. 11. 24 0:18, Miro Hrončok wrote:
The new 1.16 version of pyproject-rpm-macros is available in all Fedoras and is 
on its way to c10s and c9s.


This is now available in c10s and c9s, hence also in EPEL 10.0 and EPEL 9 Next 
Koji buildroots.


tox 4.23 is currently available in Rawhide + updates-testing on stable Fedoras. 
I will also update it in EPEL 10 soon.


tox 4.23 is now available in all Fedoras, the EPEL 10.0 update went stable 
today.

--
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

Deprecating %pyproject_buildrequires -w

[Miro Hrončok via python-devel]

Hey Pythonistas,

now when we have %pyproject_buildrequires -p, I paln to deprecate -w.

https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/502

The flag was provisional and no Fedora package needs it any more.


The -w and -p flags are both useful for build backends that don't implement the 
optional prepare-metadata-for-build-wheel hook.


 -p reads the metadata from a standardized TOML file
 -w builds the wheel and reads the metadata from it

Both of them unfortunately need to do this repeatedly.

-p is very fast, -w is slow (very slow for complex packages)

Technically, not all backends support -p. But the overlap of known backends 
that don't and those that don't have the prepare-metadata-for-build-wheel hook 
is currently empty.


--
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: Fontmake needed for generating variable font from source

[Miro Hrončok via python-devel]

On 06. 12. 24 14:40, Anirban Mitra via python-devel wrote:

Fontmake is a python tool required to generate variable fonts from designspace 
and ufo sources. I have created a variable font which I want to package for 
fedora. But I couldn't find fontmake in fedora packages. So do I need to 
package fontmake first to be able to package my font or I can install it 
through pip during the build stage of my package and list only python3 and pip 
as dependency.


Hello,
installing through pip during the build is not possible (at least not for 
official Fedora packages).


You SHOULD package fontmake first.

If that's unreasonably complicated (it shouldn't be), you might bundle it as a 
second source of your font instead.


--
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: 3 python packages for Multipart Handler

[Miro Hrončok via python-devel]

On 07. 12. 24 18:51, Sérgio Basto wrote:

Hi,

I just notice that we have in Fedora 3 python packages for Multipart
Handler [1] I'm maintainer of python-MultipartPostHandler2 and I think
the package can be orphan and retired later , because now we have one
replacement . The other two I don't know if they do the same or not.

Best regards,

[1]
https://src.fedoraproject.org/rpms/python-python-multipart
https://src.fedoraproject.org/rpms/python-multipart
https://src.fedoraproject.org/rpms/python-MultipartPostHandler2


The other two are different than each other.

--
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

Retiring python-nose from Fedora 43+

[Miro Hrončok via python-devel]

Hello,

I propose we retire python-nose from Fedora 43+ immediately after branching.

The package has been deprecated for 5 years:

  https://fedoraproject.org/wiki/Changes/DeprecateNose

It does not build with Python 3.14:

  https://bugzilla.redhat.com/2323163

We carry downstream-only patches since Python 3.5.

Currently, the following packages need it:

$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-nose --qf 
'%{name}.%{arch}'

ProDy.src
bmap-tools.src
hgsvn.src
nova-agent.src
odcs.src
openms.src
python-agate-dbf.src
python-agate-excel.src
python-agate-sql.src
python-agate.src
python-axolotl.src
python-behave.src
python-binstruct.src
python-blessings.src
python-colorspacious.src
python-curtsies.src
python-epc.src
python-eyed3.src
python-flask-xml-rpc.src
python-hglib.src
python-ifcfg.src
python-leather.src
python-migrate.src
python-moksha-common.src
python-neurosynth.src
python-ofxparse.src
python-pygeoip.src
python-pytest7.src
python-pytimeparse.src
python-queuelib.src
python-rows.src
python-sievelib.src
python-simplebayes.src
python-spec.src
python-statsd.src
python-stomper.src
python-supersmoother.src
python-tilestache.src
python-xvfbwrapper.src
python3-bmaptools.noarch
python3-neurosynth.noarch
python3-nose-testconfig.noarch
python3-spec.noarch
vigra.src


The most dependent-upon packages in the list are:

 python-behave (affects 7 packages including self)
 vigra (4)

https://src.fedoraproject.org/rpms/python-behave/pull-request/6
https://src.fedoraproject.org/rpms/vigra/pull-request/5


The entire dep tree is:

ProDy (maintained by: sagitter)
ProDy.src requires python3-nose

bmap-tools (maintained by: aekoroglu)
bmap-tools.src requires python3dist(nose)
python3-bmaptools.noarch requires python3.13dist(nose)

hgsvn (maintained by: terjeros)
hgsvn.src requires python3-hglib, python3-nose
hgsvn.noarch requires python3-hglib, python3.13dist(python-hglib)

nova-agent (maintained by: survient, tonyskapunk)
nova-agent.src requires python3-nose

odcs (maintained by: cqi, hlin, lsedlar, qwan)
odcs.src requires python3-nose

openms (maintained by: sagitter)
openms.src requires python3-nose

python-agate (maintained by: jujens)
python-agate.src requires python3-nose, python3dist(leather), 
python3dist(pytimeparse)
python3-agate.noarch requires python3.13dist(leather), 
python3.13dist(pytimeparse)


python-agate-dbf (maintained by: jujens)
python-agate-dbf.src requires python3-nose, python3dist(agate)
python3-agate-dbf.noarch requires python3.13dist(agate)

python-agate-excel (maintained by: jujens)
python-agate-excel.src requires python3-nose, python3dist(agate)
python3-agate-excel.noarch requires python3.13dist(agate)

python-agate-sql (maintained by: jujens)
python-agate-sql.src requires python3-nose, python3dist(agate)
python3-agate-sql.noarch requires python3.13dist(agate)

python-axolotl (maintained by: principis)
python-axolotl.src requires python3dist(nose)

python-behave (maintained by: @python-packagers-sig, aekoroglu)
python-behave.src requires python3-nose

python-binstruct (maintained by: besser82)
python-binstruct.src requires python3-nose

python-blessings (maintained by: @python-packagers-sig, salimma)
python-blessings.src requires python3dist(nose)

python-colorspacious (maintained by: fed500)
python-colorspacious.src requires python3-nose

python-curtsies (maintained by: salimma, terjeros)
python-curtsies.src requires python3-blessings, python3-nose
python3-curtsies.noarch requires python3-blessings

python-epc (maintained by: melmorabity)
python-epc.src requires python3dist(nose)

python-eyed3 (maintained by: amigadave, cicku, pjp)
python-eyed3.src requires python3-nose

python-flask-xml-rpc (maintained by: orphan)
python-flask-xml-rpc.src requires python3-nose

python-hglib (maintained by: terjeros)
python-hglib.src requires python3-nose

python-ifcfg (maintained by: cottsay)
python-ifcfg.src requires python3-nose

python-leather (maintained by: jujens)
python-leather.src requires python3-nose

python-migrate (maintained by: @openstack-sig, jcapitao)
python-migrate.src requires python3-nose

python-moksha-common (maintained by: @infra-sig, lbalhar)
python-moksha-common.src requires python3-nose

python-neurosynth (maintained by: @neuro-sig, lbazan)
python-neurosynth.src requires python3dist(nose)
python3-neurosynth.noarch requires python3dist(nose)

python-ofxparse (maintained by: rajeeshknambiar)
python-ofxparse.src requires python3-nose

python-pygeoip (maintained by: @infra-sig, kevin)
python-pygeoip.src requires python3-nose

python-pytest7 (maintained by: @python-packagers-sig, thrnciar)
python-pytest7.src requires python3-nose

python-pytimeparse (maintained by: mrunge, vtrefny)
python-pytimeparse.src requires python3dist(nose)

python-queuelib (maintained by: fab)
python-queuelib.src requires python3-nose

python-ro

95 packages use %pyproject_buildrequires with tox without a suitable tox configuration

[Miro Hrončok via python-devel]

Hello Pythonistas.

When we updated tox from version 3 to 4, it no longer fails when here is no 
suitable tox configuration found. This was a deliberate upstream choice.


Unfortunately, it means that packages that use %pyproject_buildrequires with -t 
or -e now silently succeed if there is no tox configuration found.


I identified 95 packages that are affected by this, see below.

Unfortunately, it is tricky to detect a missing tox configuration directly from 
%pyproject_buildrequires. For now, I did this by looking for a specific 
information in tox output, but that might not be stable.


I built all Rawhide packages matching 
%\{?pyproject_buildrequires\s+(.+\s)?-\S*[te] in a copr with a modified version 
of %pyproject_buildrequires which fails when this happens.


https://copr.fedorainfracloud.org/coprs/churchyard/pyproject-buildrequires-no-tox-error/builds/

For all the failures, I looked into the logs and identified the 95 failures are 
caused by that (see below).



If this affects your package, please consider if your usage of -t/-e for 
%pyproject_buildrequires is a mistake (and remove it), or see if some explicit 
build dependencies are missing (and the package only builds by chance).


Sometimes, upstreams which use tox don't put their tox configuration into sdist 
(%pypi_source) and only keep it in git.


Sometimes, upstreams don't use tox at all and the usage of -t/-e is wrong.

If you have questions, I am happy to help.

Maintainers by package:
hddfancontrolfiliperosset
lazygal  rathann
mat2 atim
mkdocs   dcavalca smani
moguixdelaruelle
onnx aalvarez dherrera
past-timefab
patool   eclipseo
pmbootstrap  defolos
pykkagirst
python-ailment   fab mikep
python-aioftpfab
python-aiomultiprocess fab
python-archinfo  fab mikep
python-archspec  orion
python-asn1tools peter
python-asysocks  fab
python-base58peter
python-blowfish  limb
python-ckzg  peter
python-claripy   fab mikep
python-cmd2  fab jcapitao ktdreyer
python-dataclassypeter
python-diff-match-patch amigadave
python-dropbox   limb
python-einopstrix
python-envisage  orion
python-eth-abi   peter
python-eth-account   peter
python-eth-event peter
python-eth-hash  peter
python-eth-keyfile   peter
python-eth-keys  peter
python-eth-rlp   peter
python-eth-stdlibpeter
python-eth-typingpeter
python-eth-utils peter
python-flask-httpauth jpena
python-flask-session frantisekz
python-haversion fab
python-hexbytes  peter
python-hvac  ignatenkobrain ngompa rcallicotte
python-influxdb-client fedepell stevetraylen
python-jaconvkevin
python-jsonpath-ng   fab
python-lazy_load peter
python-libusb1   jonny peter
python-logutils  limb
python-lru-dict  peter
python-mailman-web   salimma
python-migen somlo
python-morphys   peter
python-multiaddr peter
python-multibase peter
python-multicodecpeter
python-multihash peter
python-music21   zbyszek
python-nine  ondrejj
python-optking   jussilehtola
python-optunalimb
python-paginate  dcavalca
python-pandas-datareader sergiopr
python-pyaes thebeanogamer
python-pybeampeter
python-pyiqvia   fab
python-pymongo   apevec cstratak hhorak jonathanspw orion
python-pyrad antorres cicku peter
python-pytest-dependency mikelo2
python-pytest-fixture-config kevin
python-qcelemental   jussilehtola
python-requests-unixsocket jcaratzas radez
python-rlp   peter
python-rpyc  fab
python-simple-pidttorcz
python-smi   fab
python-ssdp  fab
python-telnetlib3dcavalca
python-textile   thm
python-textparserfab
python-timeout-decorator jcapitao
python-tinydbpetersen suanand
python-towncrier eclipseo
python-trie  peter
python-uhashring amoralej
python-unix-ar   ppfeister
python-warlock   apevec jcapitao mrunge
python-xlrd  ondrejj pingou
python-zstandard ignatenkobrain rathann
python3-exiv2asn
quearcodelimb
reusejstanek
rpm-spec-language-server frostyx
scancode-toolkit eclipseo
syncstar t0xic0der
vapoursynth  slaanesh

Packages by maintainer:
aalvarez   onnx
amigadave  python-diff-match-patch
amoralej   python-uhashring
antorres   python-pyrad
apevec python-pymongo python-warlock
asnpython3-exiv2
atim   mat2
cicku  python-pyrad
cstratak   python-pymongo
dcavalca   mkdocs python-paginate python-telnetlib3
defolospmbootstrap
dherrera   onnx
eclipseo   patool python-towncrier scancode-toolkit
fabpast-time python-ailment python-aioftp python-aiomultiprocess 
python-archinfo python-asysocks python-claripy python-cmd2 python-haversion 
python-jsonpath-ng python-pyiqvia python-rpyc python-smi python-ssdp 
python-text

Re: 95 packages use %pyproject_buildrequires with tox without a suitable tox configuration

[Miro Hrončok via python-devel]

On 05. 02. 25 10:47, Miro Hrončok wrote:

Hello Pythonistas.

When we updated tox from version 3 to 4, it no longer fails when here is no 
suitable tox configuration found. This was a deliberate upstream choice.


Unfortunately, it means that packages that use %pyproject_buildrequires with -t 
or -e now silently succeed if there is no tox configuration found.


I identified 95 packages that are affected by this, see below.

Unfortunately, it is tricky to detect a missing tox configuration directly from 
%pyproject_buildrequires. For now, I did this by looking for a specific 
information in tox output, but that might not be stable.


I built all Rawhide packages matching %\{?pyproject_buildrequires\s+(.+\s)?- 
\S*[te] in a copr with a modified version of %pyproject_buildrequires which 
fails when this happens.


https://copr.fedorainfracloud.org/coprs/churchyard/pyproject-buildrequires-no- 
tox-error/builds/


For all the failures, I looked into the logs and identified the 95 failures are 
caused by that (see below).



If this affects your package, please consider if your usage of -t/-e for 
%pyproject_buildrequires is a mistake (and remove it), or see if some explicit 
build dependencies are missing (and the package only builds by chance).


FWIW The following subset of packages also uses %tox, which most likely runs no 
tests (and succeeds):


Maintainers by package:
hddfancontrolfiliperosset
mkdocs   dcavalca smani
patool   eclipseo
pykkagirst
python-cmd2  fab jcapitao ktdreyer
python-diff-match-patch amigadave
python-influxdb-client fedepell stevetraylen
python-mailman-web   salimma
python-migen somlo
python-nine  ondrejj
python-paginate  dcavalca
python-pymongo   apevec cstratak hhorak jonathanspw orion
python-ssdp  fab
python-telnetlib3dcavalca
python-timeout-decorator jcapitao
python-tinydbpetersen suanand
python-warlock   apevec jcapitao mrunge
python-xlrd  ondrejj pingou
syncstar t0xic0der
vapoursynth  slaanesh

Packages by maintainer:
amigadave  python-diff-match-patch
apevec python-pymongo python-warlock
cstratak   python-pymongo
dcavalca   mkdocs python-paginate python-telnetlib3
eclipseo   patool
fabpython-cmd2 python-ssdp
fedepell   python-influxdb-client
filiperosset hddfancontrol
girst  pykka
hhorak python-pymongo
jcapitao   python-cmd2 python-timeout-decorator python-warlock
jonathanspw python-pymongo
ktdreyer   python-cmd2
mrunge python-warlock
ondrejjpython-nine python-xlrd
orion  python-pymongo
petersen   python-tinydb
pingou python-xlrd
salimmapython-mailman-web
slaanesh   vapoursynth
smani  mkdocs
somlo  python-migen
stevetraylen python-influxdb-client
suanandpython-tinydb
t0xic0der  syncstar

--
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: Let's retire pytest7 and pluggy1.3?

[Miro Hrončok via python-devel]

On 02. 02. 25 12:50, Sandro via python-devel wrote:

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.

I don't think we should mix the two things together.

I also want to retire pytest7 from f42, and nose from f43.

--
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

Let's retire pytest7 and pluggy1.3?

[Miro Hrončok via python-devel]

Hello Pythonistas.

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).



The tracking bugzilla https://bugzilla.redhat.com/2256331 now only depends on 3 
open bugzillas, all of them now have open PRs that fix them:


git-up https://bugzilla.redhat.com/2272982
https://src.fedoraproject.org/rpms/git-up/pull-request/2

python-django-extensions https://bugzilla.redhat.com/2274104
https://src.fedoraproject.org/rpms/python-django-extensions/pull-request/6

python-remoto https://bugzilla.redhat.com/2275251
https://src.fedoraproject.org/rpms/python-remoto/pull-request/3


Repoqueries:

$ comm -23 <(repoquery -q --repo=rawhide{,-source} --whatrequires 
'python3-pytest = 7' | sort) <(repoquery -q --repo=rawhide{,-source} 
--whatrequires 'python3-pytest = 8' | sort)

python-django-extensions-0:3.2.3-8.fc42.src
python-pluggy1.3-0:1.3.0-9.fc42.src

$ comm -23 <(repoquery -q --repo=rawhide{,-source} --whatrequires 
python3-pytest7 | sort) <(repoquery -q --repo=rawhide{,-source} --whatrequires 
python3-pytest | sort)

git-up-0:2.2.0-9.fc42.src
python-odata-query-0:0.10.0b1-4.fc42.src
python-watchfiles-0:1.0.3-3.fc42.src

That is (apart from already listed packages):

https://src.fedoraproject.org/rpms/python-odata-query/pull-request/7
https://src.fedoraproject.org/rpms/python-watchfiles/pull-request/4


And pluggy 1.3 is only used by pytest 7:


$ comm -23 <(repoquery -q --repo=rawhide{,-source} --whatrequires 
'python3-pluggy = 1.3' | sort) <(repoquery -q --repo=rawhide{,-source} 
--whatrequires 'python3-pluggy = 1.5' | sort)

(nothing)

$ comm -23 <(repoquery -q --repo=rawhide{,-source} --whatrequires 
'python3-pluggy1.3' | sort) <(repoquery -q --repo=rawhide{,-source} 
--whatrequires 'python3-pluggy' | sort)

python-pytest7-0:7.4.3-4.fc42.src
python3-pytest7-0:7.4.3-4.fc42.noarch


--
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: Retire Python 3.8 from Fedora 42+?

[Miro Hrončok via python-devel]

On 06. 12. 24 1:46, Miro Hrončok wrote:

On 05. 12. 24 23:24, Fabio Valentini via python-devel wrote:

On Thu, Nov 21, 2024 at 11:13 PM Miro Hrončok via python-devel
 wrote:


Hey Pythonistas,

- Python 3.8 reached upstream End of Life 2024-10-07.
- RHEL 8 Python 3.8 Stream has been retired since May 2023.
- Debian buster had Python 3.7, bullseye has 3.9.
- Ubuntu 20.04 LTS (Focal Fossa) has Python 3.8.
 - Standard support ends April 2025.

Fedora 42 release date is April 2025.

Hence I think we should retire Python 3.8 from Fedora 42+


Do it!
Will you file a Change Proposal like
https://fedoraproject.org/wiki/Changes/RetirePython3.7 ?

That is the plan.


https://fedoraproject.org/wiki/Changes/RetirePython3.8

--
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: Need help with pywt

[Miro Hrončok via python-devel]

On 19. 12. 24 16:30, Orion Poplawski via python-devel wrote:

I'm trying to update pywt to 1.6 or 1.8 here:

https://src.fedoraproject.org/rpms/python-pywt/pull-request/6

I'm running into an issue where it seems that I must install the built wheel 
locally so that I can then build the docs, but I don't know how to do that.


When I do that locally it works (network!) but then I get doc build failures as 
well.


Does moving sphinx-build after %pyproject_install work? With %py3_test_envvars.

Something like this 
https://src.fedoraproject.org/rpms/fontmake/blob/rawhide/f/fontmake.spec#_92


--
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

Retire Python 3.8 from Fedora 42+?

[Miro Hrončok via python-devel]

Hey Pythonistas,

- Python 3.8 reached upstream End of Life 2024-10-07.
- RHEL 8 Python 3.8 Stream has been retired since May 2023.
- Debian buster had Python 3.7, bullseye has 3.9.
- Ubuntu 20.04 LTS (Focal Fossa) has Python 3.8.
   - Standard support ends April 2025.

Fedora 42 release date is April 2025.

Hence I think we should retire Python 3.8 from Fedora 42+

Any other use case for Python 3.8 I missed?

--
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

Let's drop /usr/local/lib(64)/python3.X/site-packages once and for all

[Miro Hrončok via python-devel]

Hello Pythonistas.


tl;dr I wonder if we should get rid of the last downstream-only patch in 
Fedora's Python,

the one responsible for /usr/local/lib(64)/python... installation location.
The removal would bring us closer to upstream, but perhaps cause a regression 
for our users.
I propose to adapt PEP 668 (Marking Python base environments as “externally 
managed”) instead.



Details:

On Python 3.13+ we only ship one downstream-only patch in Python.
That is a patch that is not yet upstreamable, isn't a backport etc.

The patch is this:

https://src.fedoraproject.org/rpms/python3.13/blob/f39/f/00251-change-user-install-location.patch
(Deliberately linking f39 to make the link stable. Rawhide is currently the 
same.)

Or as a commit:
https://github.com/fedora-python/cpython/commit/ac3a9df5f8

We carry this patch in various forms for 7+ years.
It originated with https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe

The idea is this:

 - sudo pip install etc. installs to /usr/local/lib(64)/python3.X/site-packages
 - RPM packages are installed in /usr/lib(64)/python3.X/site-packages
 - RPM installed software ignores the packages in /usr/local (unless they opt 
in not to)

 - other software uses packages from both, giving preference to /usr/local

There are several challenges to this approach:

One of them is upgrading. Ideally if pyfoo 1 is installed via RPM,
sudo pip install --upgrade 'pyfoo>=2' should install pyfoo to /usr/local while 
leaving

the RPM-installed pyfoo 1 be.
In reality, pip is not ready for this and needs a patch as well:
https://src.fedoraproject.org/rpms/python-pip/blob/f39/f/remove-existing-dist-only-if-path-conflicts.patch
This means that users who do sudo pip install --upgrade pip lose this patch.
This also means that the fact that this appears to work in other Python package 
managers (such as uv) is probably purely accidental.
This behavior also tends to differ for RPM-packaged Python packages with 
.dist-info and .egg-info metadata.


Another challenge is the mechanism we decided to use for RPM packages to ignore 
/usr/local.

We use the -s flag in shebangs for this. That leads to problems like this:
"global pip installed modules not visible if user site dir is disabled"
https://bugzilla.redhat.com/2256190

We could probably solve this by introducing a custom flag instead of -s,
but that would make the patch even worse -- our RPM-packaged software would not 
even execute

without our Python with our patch. I don't want to do that.

A result of this problem (which is shared with Debian-based distros) was
PEP 668 – Marking Python base environments as “externally managed”
https://peps.python.org/pep-0668/
Except we cannot use it as is, because our install locations share a common 
stdlib location.
I described this at 
https://discuss.python.org/t/pep-668-marking-python-base-environments-as-externally-managed/10302/46 
and further.


At this point, after 2 years of failure, I really don't know how to get 
something from this that's upstreamable.


I spoke about this at PyCon PL '22 as well:
https://www.youtube.com/watch?v=7SBH4PkbMhw

---

Recently it occurred to me that perhaps we could:

 1. drop the patches from Python and pip
 2. mark /usr/lib(64)/python3.X as externally managed (PEP 668)

And declare sudo-pip-installing unsupported. (That means, it only works with a 
custom pip flag and if users nuke their systems by using that flag, they shot 
themelves and we cannot help them.)


Personally, I think this would be the best solution:
sudo-pip-installing is bad and should never be done (no, not even in 
containers).

However, I realize that others might disagree. For them, I can offer pip 
--break-system-packages.



If we want to do this, I think we need to do this on Python upgrade boundary.
We don't want users sudo pip-installing packages with Python 3.13 on Fedora 41 
only to find them

ignored on Fedora 42.
However, when we upgrade Python to 3.14 in Fedora 43, their packages would 
still be broken anyway.


--
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: Retire Python 3.8 from Fedora 42+?

[Miro Hrončok via python-devel]

On 05. 12. 24 23:24, Fabio Valentini via python-devel wrote:

On Thu, Nov 21, 2024 at 11:13 PM Miro Hrončok via python-devel
 wrote:


Hey Pythonistas,

- Python 3.8 reached upstream End of Life 2024-10-07.
- RHEL 8 Python 3.8 Stream has been retired since May 2023.
- Debian buster had Python 3.7, bullseye has 3.9.
- Ubuntu 20.04 LTS (Focal Fossa) has Python 3.8.
 - Standard support ends April 2025.

Fedora 42 release date is April 2025.

Hence I think we should retire Python 3.8 from Fedora 42+


Do it!
Will you file a Change Proposal like
https://fedoraproject.org/wiki/Changes/RetirePython3.7 ?

That is the plan.

--
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: Let's drop /usr/local/lib(64)/python3.X/site-packages once and for all

[Miro Hrončok via python-devel]

On 06. 12. 24 18:31, Neal Gompa via python-devel wrote:

On Fri, Dec 6, 2024 at 12:04 PM Fabio Valentini via python-devel
 wrote:


On Tue, Dec 3, 2024 at 7:03 PM Miro Hrončok via python-devel
 wrote:


Hello Pythonistas.


tl;dr I wonder if we should get rid of the last downstream-only patch in
Fedora's Python,
the one responsible for /usr/local/lib(64)/python... installation location.
The removal would bring us closer to upstream, but perhaps cause a regression
for our users.
I propose to adapt PEP 668 (Marking Python base environments as “externally
managed”) instead.


We shouldn't cater to ancient / broken tutorials and / or use cases
that have always been "wrong" for all eternity, IMO.
virtualenvs have existed in some shape or form for almost two decades
(the venv module was added in Python 3.3 - in 2012!) - people should
just use those.

So I say "do it". If you make this a Change proposal, I'd vote +1 on it.



Another option would be to shift our stuff out of site-packages and
into a new directory (dist-packages like debian, maybe?). If RPM
packaged stuff went there and everything else went into site-packages,
that would effectively retain the same spirit as what we do now.


Yet it would not solve any of the problems.

--
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: Let's drop /usr/local/lib(64)/python3.X/site-packages once and for all

[Miro Hrončok via python-devel]

On 06. 12. 24 18:56, Neal Gompa wrote:

On Fri, Dec 6, 2024 at 12:48 PM Miro Hrončok via python-devel
 wrote:


On 06. 12. 24 18:31, Neal Gompa via python-devel wrote:

On Fri, Dec 6, 2024 at 12:04 PM Fabio Valentini via python-devel
 wrote:


On Tue, Dec 3, 2024 at 7:03 PM Miro Hrončok via python-devel
 wrote:


Hello Pythonistas.


tl;dr I wonder if we should get rid of the last downstream-only patch in
Fedora's Python,
the one responsible for /usr/local/lib(64)/python... installation location.
The removal would bring us closer to upstream, but perhaps cause a regression
for our users.
I propose to adapt PEP 668 (Marking Python base environments as “externally
managed”) instead.


We shouldn't cater to ancient / broken tutorials and / or use cases
that have always been "wrong" for all eternity, IMO.
virtualenvs have existed in some shape or form for almost two decades
(the venv module was added in Python 3.3 - in 2012!) - people should
just use those.

So I say "do it". If you make this a Change proposal, I'd vote +1 on it.



Another option would be to shift our stuff out of site-packages and
into a new directory (dist-packages like debian, maybe?). If RPM
packaged stuff went there and everything else went into site-packages,
that would effectively retain the same spirit as what we do now.


Yet it would not solve any of the problems.



I thought EXTERNALLY-MANAGED works off the install scheme? If one
scheme is locked but the other isn't, it should be fine, right?

Yes, but we still hit all of the problems described in my original email.

--
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: Retiring python-nose from Fedora 43+

[Miro Hrončok via python-devel]

On 11. 01. 25 23:02, Nico Kadel-Garcia wrote:

The dependency chains still using python-nose are pretty popular, and
include awscli and Samba. This may not be as easy as it  seems at
first glance.


Could you please point out that dependency trees? I see neither package as 
affected by nose retirement directly or indirectly.


--
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: Retiring python-nose from Fedora 43+

[Miro Hrončok via python-devel]

On 06. 01. 25 12:45, Miro Hrončok wrote:

Hello,

I propose we retire python-nose from Fedora 43+ immediately after branching.

The package has been deprecated for 5 years:

   https://fedoraproject.org/wiki/Changes/DeprecateNose

It does not build with Python 3.14:

   https://bugzilla.redhat.com/2323163

We carry downstream-only patches since Python 3.5.

Currently, the following packages need it:

$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-nose --qf 
'%{name}.%{arch}'

...


The most dependent-upon packages in the list are:

  python-behave (affects 7 packages including self)
  vigra (4)


Due to a fix in the python-httpretty package which once again built it with 
tests:

https://src.fedoraproject.org/rpms/python-httpretty/pull-request/33

The dependency tree is now once again enormous and contains 1000+ packages.

Removing that dependency is now the top priority before nose can be removed.

--
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: Retiring python-nose from Fedora 43+

[Miro Hrončok via python-devel]

On 16. 01. 25 13:29, Miro Hrončok wrote:

On 06. 01. 25 12:45, Miro Hrončok wrote:

Hello,

I propose we retire python-nose from Fedora 43+ immediately after branching.

The package has been deprecated for 5 years:

   https://fedoraproject.org/wiki/Changes/DeprecateNose

It does not build with Python 3.14:

   https://bugzilla.redhat.com/2323163

We carry downstream-only patches since Python 3.5.

Currently, the following packages need it:

$ repoquery -q --repo=rawhide{,-source} --whatrequires python3-nose --qf 
'%{name}.%{arch}'

...


The most dependent-upon packages in the list are:

  python-behave (affects 7 packages including self)
  vigra (4)


Due to a fix in the python-httpretty package which once again built it with 
tests:

https://src.fedoraproject.org/rpms/python-httpretty/pull-request/33

The dependency tree is now once again enormous and contains 1000+ packages.

Removing that dependency is now the top priority before nose can be removed.

https://src.fedoraproject.org/rpms/python-httpretty/pull-request/34

--
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_buildrequires -t/-e and %tox without a suitable tox configuration will error

[Miro Hrončok via python-devel]

Hello packagers.

As a followup to this email sent a month ago to the python-devel list, I now 
plan to make the incorrect (and unsafe) usage of %pyproject_buildrequires -t/-e 
and %tox without a suitable tox configuration fail the build.


This is a breaking change, but I believe it's the only way to prevent packages 
with always passing %checks.


If your package has no tox configuration, do not use the -t/-e option for 
%pyproject_buildrequires, do not use %tox.


This change will land to rawhide first and later to all stable releases as well.

For reference:
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/512

On 05. 02. 25 10:47, Miro Hrončok wrote:

Hello Pythonistas.

When we updated tox from version 3 to 4, it no longer fails when here is no 
suitable tox configuration found. This was a deliberate upstream choice.


Unfortunately, it means that packages that use %pyproject_buildrequires with -t 
or -e now silently succeed if there is no tox configuration found.


I identified 95 packages that are affected by this, see below.

Unfortunately, it is tricky to detect a missing tox configuration directly from 
%pyproject_buildrequires. For now, I did this by looking for a specific 
information in tox output, but that might not be stable.


I built all Rawhide packages matching %\{?pyproject_buildrequires\s+(.+\s)?- 
\S*[te] in a copr with a modified version of %pyproject_buildrequires which 
fails when this happens.


https://copr.fedorainfracloud.org/coprs/churchyard/pyproject-buildrequires-no- 
tox-error/builds/


For all the failures, I looked into the logs and identified the 95 failures are 
caused by that (see below).



If this affects your package, please consider if your usage of -t/-e for 
%pyproject_buildrequires is a mistake (and remove it), or see if some explicit 
build dependencies are missing (and the package only builds by chance).


Sometimes, upstreams which use tox don't put their tox configuration into sdist 
(%pypi_source) and only keep it in git.


Sometimes, upstreams don't use tox at all and the usage of -t/-e is wrong.

If you have questions, I am happy to help.

Maintainers by package:
hddfancontrol    filiperosset
lazygal  rathann
mat2 atim
mkdocs   dcavalca smani
mogui    xdelaruelle
onnx aalvarez dherrera
past-time    fab
patool   eclipseo
pmbootstrap  defolos
pykka    girst
python-ailment   fab mikep
python-aioftp    fab
python-aiomultiprocess fab
python-archinfo  fab mikep
python-archspec  orion
python-asn1tools peter
python-asysocks  fab
python-base58    peter
python-blowfish  limb
python-ckzg  peter
python-claripy   fab mikep
python-cmd2  fab jcapitao ktdreyer
python-dataclassy    peter
python-diff-match-patch amigadave
python-dropbox   limb
python-einops    trix
python-envisage  orion
python-eth-abi   peter
python-eth-account   peter
python-eth-event peter
python-eth-hash  peter
python-eth-keyfile   peter
python-eth-keys  peter
python-eth-rlp   peter
python-eth-stdlib    peter
python-eth-typing    peter
python-eth-utils peter
python-flask-httpauth jpena
python-flask-session frantisekz
python-haversion fab
python-hexbytes  peter
python-hvac  ignatenkobrain ngompa rcallicotte
python-influxdb-client fedepell stevetraylen
python-jaconv    kevin
python-jsonpath-ng   fab
python-lazy_load peter
python-libusb1   jonny peter
python-logutils  limb
python-lru-dict  peter
python-mailman-web   salimma
python-migen somlo
python-morphys   peter
python-multiaddr peter
python-multibase peter
python-multicodec    peter
python-multihash peter
python-music21   zbyszek
python-nine  ondrejj
python-optking   jussilehtola
python-optuna    limb
python-paginate  dcavalca
python-pandas-datareader sergiopr
python-pyaes thebeanogamer
python-pybeam    peter
python-pyiqvia   fab
python-pymongo   apevec cstratak hhorak jonathanspw orion
python-pyrad antorres cicku peter
python-pytest-dependency mikelo2
python-pytest-fixture-config kevin
python-qcelemental   jussilehtola
python-requests-unixsocket jcaratzas radez
python-rlp   peter
python-rpyc  fab
python-simple-pid    ttorcz
python-smi   fab
python-ssdp  fab
python-telnetlib3    dcavalca
python-textile   thm
python-textparser    fab
python-timeout-decorator jcapitao
python-tinydb    petersen suanand
python-towncrier eclipseo
python-trie  peter
python-uhashring amoralej
python-unix-ar   ppfeister
python-warlock   apevec jcapitao mrunge
python-xlrd  ondrejj pingou
python-zstandard ignatenkobrain rathann
python3-exiv2    asn
quearcode    limb
reuse    jstanek
rpm-spec-language-server frostyx
scancode-toolkit eclipseo
syncsta

Re: Fedora 43 Python 3.14 rebuild in a side tag starts today

[Miro Hrončok via python-devel]

Hi.

The rebuild is stuck. We have ~600 packages left to rebuild (from ~4250).

At this point, we'd like to merge, but we are investigating some OpenQA 
failures that might (or might not) be related.


In the meantime, please continue following the instructions: Do not build 
Python packages in rawhide. And if you manage to fix some of the missing 
packages, build it in f43-python please.


Thanks.
Miro

On 02. 06. 25 9:52, Karolina Surma wrote:

Hello,

We are starting the Python 3.14 mass rebuild in the side tag for
Fedora 41 with Python 3.14.0b2.

Please, follow the original instructions when planning to build your
Python packages.
We'll let you know when we'll plan to merge the side tag.

And... keep your fingers crossed :)
Karolina



On 5/28/25 14:28, Karolina Surma wrote:

Hello,

To deliver Python 3.14 with Fedora Linux 43, we will run a coordinated
rebuild in a side tag.

https://fedoraproject.org/wiki/Changes/Python3.14

Python 3.14.0b2 has been released on Monday, May 26th, 2025 and shipped in 
all Fedoras.

We hope to start the mass rebuild beginning next week.

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.14.

Details:
If you see a "Rebuilt for Python 3.14" (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=f43-python
    $ koji wait-repo f43-python --build  --request

It takes time to build all the essential packages,
so don't expect all your dependencies to be available right away.
Any attempts to build your packages in the side tag before we do will
likely fail due to missing dependencies.

When in trouble, ask here or on Fedora's Matrix - Fedora Python room
(https://matrix.to/#/#python:fedoraproject.org)
Ping me (ksurma) or Miro (mhroncok) if you need to talk to us.

Builds will appear here:
https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f43- 
python&inherited=0


Please avoid any potentially disturbing or major changes in Python
packages until the rebuild is over.

Thanks!
Karolina






--
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 43 Python 3.14 mass rebuild status [DONE]

[Miro Hrončok via python-devel]

On 11. 06. 25 16:49, Łukasz Wojniłowicz wrote:

On 25-06-11 09:47, Karolina Surma wrote:

Hello,

On 6/10/25 11:35, Karolina Surma wrote:

The Python 3.14 rebuild is in progress. We plan to merge the side tag soon.



The side tag has been merged. Now you can build Python packages in
regular Rawhide with Python 3.14 safely.
Shortly we'll start opening bugzillas for the remaining packages.


Hi,
why not start rebuilding the remaining packages instead?


Hi. I am a tad confused. We keep building the packages as they become unblocked 
by dependencies.



A ticket has been opened for my package at
https://bugzilla.redhat.com/show_bug.cgi?id=2371806 because it fails due to
a missing dependency https://src.fedoraproject.org/rpms/python-click, which got 
rebuilt with an automatic commit at https://src.fedoraproject.org/rpms/python- 
click/c/60e852252bb6ce0b18b1f0301dcf843dfb40e341?branch=rawhide


But that's not failing because of click. click has indeed been built already.

We are working on automatically marking that bugzilla blocked on what it 
actually needs.


It's python-peewee which is itself blocked on protobuf which does not build.


I believe it would save everybody time with opening/closing tickets and
then manually rebuilding all the packages just to see that everything is
fine.


What do you mean by "everything is fine"?

--
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

%py_byte_compile compiles .py files with dashes, should it?

[Miro Hrončok via python-devel]

Hi Pythonistas.

I have just realized, that the %py_byte_compile macro, when invoked like this:

  %py_byte_compile %{python3} %{buildroot}%{_datadir}/nemo*

Will happily compile files like

  /usr/share/nemo-compare/__pycache__/nemo-compare-preferences.cpython-313.pyc
  
/usr/share/nemo-pastebin/__pycache__/nemo-pastebin-configurator.cpython-313.pyc
  /usr/share/nemo-terminal/__pycache__/nemo-terminal-prefs.cpython-313.pyc

But such files are not (easily) importable modules.

Should it only compile .py files with importable names?

--
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 43 Python 3.14 mass rebuild status [DONE]

[Miro Hrončok via python-devel]

On 12. 06. 25 17:02, Łukasz Wojniłowicz wrote:
Thanks. I wrote that, because bugzilla mentioned python-click. I didn't know 
that bugzilla wasn't working properly. It's confusing.


So the bugzilla says "nothing provides python3.13dist(click) needed by 
python3-aw-core-0.5.17-3.fc42.noarch" which might give a false impression that 
click is somehow blocking this.


However, the real important part is "3.13", not "click". The error means:

This package has Python 3.13 runtime requires that are no longer available 
because the dependencies were rebuilt with 3.14. This package needs to be 
rebuilt with Python 3.14 so it requires python3.14dist(click) instead.



Out of curiosity, how did you come up with python-peewee? It's not
mentioned in the bugzilla.


When you scratchbuild the package, you'll get:

  nothing provides python(abi) = 3.13 needed by python3-peewee

See for example https://koschei.fedoraproject.org/package/python-aw-core


I believe it would save everybody time with opening/closing tickets and
then manually rebuilding all the packages just to see that everything is
fine.


What do you mean by "everything is fine"?


I meant, that after finally building it myself, I would conclude that
"everything is fine". I based my knowledge on python-click, which is
fine but reported missing in my ticket. I was of the impression that you
wanted me to do the obvious move, and build manually my package against
its all fine building dependencies.


For cases where everything is actually fine, we'll handle the builds.

--
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

PSA: Using %pyproject_wheel and/or %pyproject_install without %pyproject_buildrequires is not supported

[Miro Hrončok via python-devel]

Hello Python packagers,

as many are currently migrating from the old Python RPM macros to the new due 
to https://fedoraproject.org/wiki/Changes/DeprecateSetuppyMacros I'd like to 
reiterate:


  %generate_buildrequires
  %pyproject_buildrequires [options...]

This is MANDATORY when you use %pyproject_wheel and/or %pyproject_install.

The %pyproject_wheel and %pyproject_install macros have dependencies that are 
generated by %pyproject_buildrequires. Currently, that is python3-pip, 
python3-packaging and pyproject-rpm-macros. But the list is not stable and may 
change at any point. For example, if we stop using python3-pip to build the 
wheel and start using python3-build instead, packages without 
%pyproject_buildrequires would break.


(pyproject-rpm-macros do not Require those packages as the macros are usable 
with arbitrary Python versions.)


Packages without %pyproject_buildrequires and without a manual BuildRequires on 
pyproject-rpm-macros do not build on RHEL/EPEL.


Packages without %pyproject_buildrequires and without a manual BuildRequires on 
python3-packaging are relying on an indirect transitive dependency from 
python3-rpm-geneartors.


Please, always add the %generate_buildrequires section when converting packages 
to pyproject macros.


===

If you cannot use %pyproject_buildrequires, let's talk about a solution to 
this. Perhaps we could produce a pyproject-rpm-macros-static-buildrequires 
metapackage with the curated set of Requires?


But if you really need this, please tell me your reasons.

===

Maintainers by package:
boom-bootbgurney bmr mcsontos
congruityadamwill swt2c
cvc5 jjames
cxxtest  mgieseki
flatpak-module-tools kalev otaylor yselkowitz
grammalecte  melmorabity
knot jruzicka pwouters
lensfun  germano grahamwhiteuk nphilipp rdieter trix
libcpuid martinkg
libmamba orion
llama-cppman2dev trix
menulibrelyessaadi
onnxruntime  aalvarez dherrera
python-PyRSS2Gen adamwill
python-Pympler   limb
python-adafruit-platformdetect orphan
python-animatplotdavidsch
python-azure-sdk-tools jcline
python-binary-memcached amoralej
python-click-spinner thebeanogamer
python-collada   hobbes1069
python-contextualbandits iztokf
python-filecheck rathann
python-ipyparallel   ellert
python-isal  ellert
python-metakernelellert
python-mimerenderadamwill
python-psycopg3  anezbeda ndavidov osloup
python-pyownet   ttorcz
python-resultsdb_api adamwill
python-scikit-image  orion sergiopr
python-scikit-uplift iztokf
radicale jorti pbiering till
rpkg cqi lsedlar onosek
torbrowser-launcher  limb pjp
tortoisehg   kiilerix nbecker
tpm2-pkcs11  dcavalca jjelen pbrobinson

Packages by maintainer:
aalvarez   onnxruntime
adamwill   congruity python-PyRSS2Gen python-mimerender python-resultsdb_api
amoralej   python-binary-memcached
anezbeda   python-psycopg3
bgurneyboom-boot
bmrboom-boot
cqirpkg
davidsch   python-animatplot
dcavalca   tpm2-pkcs11
dherrera   onnxruntime
ellert python-ipyparallel python-isal python-metakernel
germanolensfun
grahamwhiteuk lensfun
hobbes1069 python-collada
iztokf python-contextualbandits python-scikit-uplift
jcline python-azure-sdk-tools
jjames cvc5
jjelen tpm2-pkcs11
jorti  radicale
jruzicka   knot
kalev  flatpak-module-tools
kiilerix   tortoisehg
limb   python-Pympler torbrowser-launcher
lsedlarrpkg
lyessaadi  menulibre
man2devllama-cpp
martinkg   libcpuid
mcsontos   boom-boot
melmorabity grammalecte
mgieseki   cxxtest
nbeckertortoisehg
ndavidov   python-psycopg3
nphilipp   lensfun
onosek rpkg
orion  libmamba python-scikit-image
orphan python-adafruit-platformdetect
osloup python-psycopg3
otaylorflatpak-module-tools
pbiering   radicale
pbrobinson tpm2-pkcs11
pjptorbrowser-launcher
pwouters   knot
rathannpython-filecheck
rdieterlensfun
sergiopr   python-scikit-image
swt2c  congruity
thebeanogamer python-click-spinner
till   radicale
trix   lensfun llama-cpp
ttorcz python-pyownet
yselkowitz flatpak-module-tools

Thanks.

--
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: Using pyproject macros when setup.py isn't in root directory

[Miro Hrončok via python-devel]

On 09. 07. 25 4:31, Scott Talbert via python-devel wrote:
Is there any way to use the pyproject macros when setup.py isn't in the root 
directory?


I maintain a couple of packages where this is the case - one where there are 
actually two PyPI packages built from the same source package, and another 
where the Python package is in a subdirectory because it's bindings for a C 
library that is also built.


When I try, I get this error during build:
+ echo 'ERROR: Neither pyproject.toml nor setup.py found, consider using 
%pyproject_buildrequires -N  if this is not a Python package.'
ERROR: Neither pyproject.toml nor setup.py found, consider using 
%pyproject_buildrequires -N  if this is not a Python package.


There aren't requirements files in the upstream packages.  But I guess I could 
make a downstream one?
This is only useful when you want to use an exiting requirements file in a 
piece of software that is *not* a Python package. Which the macro thinks is 
your case, as it did not find a pyproject.toml or a setup.py file.


To locate the files, simply cd to the directory before using the macro.

  %generate_buildrequires
  cd subdirectory
  %pyproject_buildrequires

  %build
  ...
  cd subdirectory
  %pyproject_wheel

Note: Make sure not to use pushd or cd - without >&2 in 
%pyproject_buildrequires, as those commands put output on the stdout and all 
stdout is considered as generated BuildRequires.


--
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: Using pyproject macros when setup.py isn't in root directory

[Miro Hrončok via python-devel]

On 10. 07. 25 2:45, Scott Talbert wrote:


The one thing - %pyproject_save_files can't work in the case of building 
multiple wheels in the same package, right?


Correct. As ow now, it has no API to say "save files from package X", so when 
multiple wheels are installed in %pyproject_install, we bail out and no longer 
allow %pyproject_save_files.


Obviously, this is somethign we could design, but the amount of such spec files 
in Fedora is rather low, and they can function with manual %file section.


--
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