GNU bug report logs - #46848
[PATCHES] [core-updates] PEP 517 python-build-system

Previous Next

Full log

Message #14 received at 46848 <at> debbugs.gnu.org (full text, mbox):

From: Hartmut Goebel <h.goebel <at> crazy-compilers.com>
To: Lars-Dominik Braun <lars <at> 6xq.net>
Cc: guix-devel <at> gnu.org, Tanguy LE CARROUR <tanguy <at> bioneland.org>,
 46848 <at> debbugs.gnu.org
Subject: Re: Questions regarding Python packaging
Date: Tue, 22 Jun 2021 09:00:54 +0200

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.