Blocking a few bugs that we can fix together with this.

But what actually needs to change?  What would a specfile look like (without any fancy macros) for something using each of these new buildsystems?  How uniform is the packaging expected to be?

Given an example spec and some idea of how much things are expected to deviate from it, we can start to cook up macros where they would be helpful and look at whether there would be benefit from various RPM features (including ones that aren't yet released).

We are working towards answers for those questions. I'm meeting with Petr IRL this week to discuss this.

> How uniform is the packaging expected to be?

The PEPs actually define an uniform layer on top of custom tools with fallback to the old de facto standard (setup.py with setuptools). So the answer is "very uniform".

This is more or less what we have:

%pyproject_wheel: <flags...> %{__python3} -m pip wheel --no-deps --use-pep517 --no-build-isolation --progress-bar off --verbose .
+ conditional --global-option and --build-option based on %{?py_setup_args} and/or other macros.

%pyproject_install: %{__python3} -m pip install --root %{buildroot}  --strip-file-prefix %{buildroot} --no-deps  --progress-bar off *.whl


Problems:

1) We cannot tell what's the wheel name yet. We need to ask pip to provide us the filename, so we can parse it form the output and store it for %pyproject_install. We should probably say this in non-normative "Recommendations for build frontends" in PEP 517.

2) The setup.py --executable option is gone and we need to figure out what to do instead to set shebangs to /usr/bin/python3 -s.


We've also discussed BuildRequires generators briefly (should be possible with PEP 517), but decided not to block the above on that.

Next steps:

1) contact pip and/or amend PEP 517 about the wheel filename
2) examine shebang options, maybe use pathfix.py after install

> 1) contact pip and/or amend PEP 517 about the wheel filename

https://discuss.python.org/t/pep-517-build-frontends-to-inform-users-about-wheel-basename/1026

setuptools 40.9.0 got released today:

https://setuptools.readthedocs.io/en/latest/history.html#v40-9-0

"Added support for setup.cfg-only projects when using the setuptools.build_meta backend. Projects that have enabled PEP 517 no longer need to have a setup.py and can use the purely declarative setup.cfg configuration file instead."

(In reply to Miro Hrončok from comment #4)
 
> Next steps:
> 
> 1) contact pip and/or amend PEP 517 about the wheel filename
PR for option to save the basenames of wheel: https://github.com/pypa/pip/pull/6377
> 2) examine shebang options, maybe use pathfix.py after install
after few package built by these macros seems there is not problem with shebangs.
Need to make more research.

> there is not problem with shebangs

Yet I'd pretty much love to keep using the -s option in shebangs of our packages.

I've just talked to Patrik IRL. We decided to add a flag to pathfix.py that can be sued to... add simple flags to shebangs.

Something like:

pathfix.py -i /usr/bin/python3 -f s

And it will convert shebangs like this:

  python -> /usr/bin/python3 -s

  python -s -> /usr/bin/python3 -s

  python -u -> /usr/bin/python3 -su

  python -us -> /usr/bin/python3 -us

  python -W xxx -> /usr/bin/python3 -sW xxx


Petrik will prep a proof of concept.

More details: This will for now only support simple flags without values. In a way, it will exactly fit our use case and we will not need to handle complicated flag merges like proposed in bz1335203.

Please check out if this may be the wanted result https://github.com/PatrikKopkan/cpython/commits/master

I've supplied some comments to the GitHub commits. However I don't think it is a best way to provide feedback. Could you open a GitHub pull request *against your own fork*?

See https://src.fedoraproject.org/rpms/pyproject-rpm-macros

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.