Hi Lars,

sorry for being late for commenting on this (the time I can spend on 
guix is rather limited atm).

Here are some general remarks on this patch-set (in order of appearance):

  *

    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.

> 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?)
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 
:-)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |