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.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
