Hi Hartmut, > sorry for being late for commenting on this (the time I can spend on > guix is rather limited atm). no problem, same thing on my side.
> * > > 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. True. We could rename python→python-minimal-interpreteronly (or similar; given that python-minimal already exists) and python-toolchain→python to work around that. > * > > "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. Yeah, I’ve seen those, but the number was too small to bother for now. I’ll have a look later. > * > > 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.) Is this relevant though? I doubt many packages are still importing distutils and the few that do can be patched. > * > > set-SOURCE-DATE-EPOCH: Please keep the verbose rational. It's much > more helpful than the new one-line comment. You mean the one from the now-removed ensure-no-mtimes-pre-1980? Sure. > * > > set-SOURCE-DATE-EPOCH: This implementation makes the code depend on > wheel and wheel being used for installation. Technically it depends on the wheel builder understanding SOURCE_DATE_EPOCH (not necessarily python-wheel). I’d say that’s acceptable and it’d be preferable to fix build systems not respecting this variable imo. > * > > Why has rename-pth-file been removed? Are you sure .pth-files are > never created anymore nowerdays? Given that easy-install has been deprecated I think it’s safe to remove this phase and flag any packages creating this easy-install.pth as broken. (There are, however, legitimate packages creating files like ruamel.yaml-0.15.83-py3.8-nspkg.pth.) > * > > 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). Afaik the function patch-shebang expects a leading slash and thus it does not replace this “special” shebang (see https://www.python.org/dev/peps/pep-0427/#installing-a-wheel-distribution-1-0-py32-none-any-whl; Spread, point 3). > * > > I suggest to have phase compile-bytecode still honor older versions > of python I’m not sure what you mean. compileall is also part of Python 2. > pypa bulld is where the PyPA is pushing towards. Anyhow, as of today, as > far as I can see, adoption is low. Of pypa build? That is true. > 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? I’m not aware of any accepted PEP’s. There is a discussion about the removal of `python setup.py test`: https://github.com/pypa/setuptools/issues/931 And a proposal for pyproject.toml going nowhere: https://discuss.python.org/t/proposal-for-tests-entry-point-in-pyproject-toml/2077/2 > 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. If we keep setuptools/pip bundled, we don’t have to do any of this pypa-build dance. We could also modernize python-build-system around `pip install` and just be done with it. (I don’t have a proof-of-concept for that yet.) > "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. See suggestion above wrt renaming. > 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 > :-) I’m using Python’s zipfile module already. Cheers, Lars