Re: Questions regarding Python packaging

[Hartmut Goebel <h.goebel@crazy-compilers.com>]

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
> ruamel.yaml-0.15.83-py3.8-nspkg.pth.)

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
> https://www.python.org/dev/peps/pep-0427/#installing-a-wheel-distribution-1-0-py32-none-any-whl;
> 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 ;-)

-- 
Regards
Hartmut Goebel

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