[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: Tue, 22 Jun 2021 09:00:54 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

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

(This shim ensures setuptools is used, even if only imports distutils. And setuptools is required for some options like ""--single-version-externally-managed" - as the comment for the shim says.)

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
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 :-)
Hartmut Goebel

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

reply via email to

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