Re: Questions regarding Python packaging

[Lars-Dominik Braun <lars@6xq.net>]

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