Not installing pip by default might break some user's environments. Anyhow, since using pip in guix is not such a good idea anyway, this should be okay.
"use-setuptools" is gone. There are still about 10 packages with "#:use-setuptools #f" - which means they are (expected to be) incompatible with setuptools for some reason. You might want to check whether these packages actually still can't be packages with setuptools.
setuptools-shim has been removed. I don't think this is a good idea, since this peace of code enforces packages to be actually build with setuptools instead of old distutils. This code is still in current pip, so I assume it is still required.
(This shim ensures setuptools is used, even if setup.py only imports distutils. And setuptools is required for some options like ""--single-version-externally-managed" - as the comment for the shim says.)
set-SOURCE-DATE-EPOCH: Please keep the verbose rational. It's much more helpful than the new one-line comment.
set-SOURCE-DATE-EPOCH: This implementation makes the code depend on wheel and wheel being used for installation.
Why has rename-pth-file been removed? Are you sure .pth-files are never created anymore nowerdays?
python-hashbang: Isn't this done already by the normal "patch-shebangs" phase after install in gnu-build-system? (BTW: these are called *she*bangs).
I suggest to have phase compile-bytecode still honor older versions of python
1) Validate the general idea of using pypa-build is viable and sustainable in the long run – ideally through review by someone else than me. We can’t touch python-build-system every week to solve structural issues, so it needs to be bullet-proof.
pypa bulld is where the PyPA is pushing towards. Anyhow, as of
today, as far as I can see, adoption is low.
2) Figure out how to run testing code. Currently python-build-system just picks pytest, if available – not sure this is the best option we have. How do we deal with other test systems? How do we pass options?
AFAIK fhere is no standard way for running tests in python. pytest seems to be the most modern test-system. Anyhow packages still use nose or tox (which again might run pytest or nose, with parameters fetched from tox.ini). So I'm afraid, there is no general rule.
Did the PyPA publish some recommendations or PEP on this?
4) Iron out minor details like including pip in the python package or create a new python-toolchain package? What do we include in that meta-package? pip? virtualenv? …?
As I Python developer I nowerdays would expect pip and venv (which is part of the std-lib - but not the virualenv, which is a separate module) to be availalbe when installing "python". Anyhow I could live with pip being a separate package.
"python-toolchain" sounds oversized for me. Would this include the C-compiler, too (which one? maybe I want to build cross). I'd rather not have such a package.
The gnu-build-system already provides the "unzip" binary (used in phase "unpack"). So we could simply use this. Otherwise I recommend using the Python zip module, as this is what is used for creating the zip-archives :-)5) Fix my awkward Scheme code, especially regarding unpacking of the built wheels. Should we be using Python’s unzip module or can be assumed unzip is available in the build environment? (Should we add it?)
-- Regards Hartmut Goebel | Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |