[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions regarding Python packaging

From: Hartmut Goebel
Subject: Re: Questions regarding Python packaging
Date: Mon, 28 Jun 2021 22:37:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

Hi Lars-Dominik,

Am 28.06.21 um 13:59 schrieb Lars-Dominik Braun:*
     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.

What should be the use of having a package without pip? Anything else than saving a few KB?

[setuptools-shim has been removed]
Is this relevant though? I doubt many packages are still importing
distutils and the few that do can be patched.

Was I wrote: This code is still in pip, so I assume it is still relevant.

I don't think patching is a good idea. It requires effort (implementing, reviewing), which can be saved by keeping exisiting and tested code.

     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.

For this case please change the comment not not referring to wheel in this way. More something like "we expect the builder to support SOURCE_DATE_EPOCH, like wheel does"

Anyhow, *m not actually convinced that we should throw away the old code. I can imagine in the next cuple of years quite some new build-systems to arrive, most of which will most probably not support SOURCE_DATE_EPOCH in the beginning, and thus making package's life harder.

     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

What exaclty do you mean with "flag as broken"? Will anybody (you? ;-) verify *all* current packages to not be "broken" prior to merging this change?

Anyhow, again, I'm not convinced we should remove this phase now. .pth-file are deprecated only, but still supported. By removing this phase we might create conflict cased we can not foresee. And I would keep it even if one analyzes none of the current packages is "broken" - just do be on the save side fpr avoiding user trouble. (These issues will show up at the user, and are hard to track down, since noone will think about .pth files)

     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;
Spread, point 3).

IC. Please add a comment to make this clear (e.g. "handle shebang of scripts generated by wheel missing leading slash")


     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.

The old code did not compile the source for Python <3.7. Please see the comment of the old code for rational.

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.)

AFAIK this might not be true if other build systems not using setuptools at all might show up. And isn't this the main reason for all your work?

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.
Fine, so you can safely remove the respective comment ;-)

Hartmut Goebel

| Hartmut Goebel          |               |
| | compilers which you thought are impossible |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]