[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, 9 Nov 2020 17:54:36 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
Hi,
seems like another messages of mine, regarding the first thread about a
poetry build system, did not make it to the list.
Am 08.11.20 um 15:27 schrieb Tanguy Le Carrour:
I've just learned, by accident (working on `python-keyring` [1]), that
`python setup.py install` was somehow deprecated
This statement is not exactly true - well, depending on interpretation
of "somehow". I've not set seen an official deprecation.
It's true that users are encouraged to use pip for installing packages.
But the official Python Packaging Tutorial [1] is still based on
setuptools (not even recommending a setup.cfg file). Thus setuptools
will be around for quite some more time, as will "python setup.py install".
In the future Python world, any build-tool can be specified in
"pyproject.toml". User will then call "pip install", and pip will
(AFAIU) call a Python function (aka entry-point) specified in that file.
(If this file does not exist, setuptools are assumed). For our
python-build-system, we would use "pip wheel" (for phase build) and "pip
install" (for phase install).
So, if we switch to "pip wheel" and "pip install", different python
build systems could share a common base, just redefining some
dependencies (setuptools, poetry, build, ...) and some tool-dependent
flags. Is this the direction you are working towards?
[1] https://packaging.python.org/tutorials/packaging-projects/
in favor of tools like`pep517` or `build`.
Thanks for point to these, both are new to me.
"build" sounds interesting, esp. for guix: "It is a simple build tool
and does not perform any dependency management." This would help us
spliting dependency management and build phase. Anyhow, it's quite new
(half an year old) and implements a PEP 517 package builder - and PEP
517 (defining the build system in pyproject.toml) is not yet adopted widely.
"pep517" seems o be a library used for "build". Its high-level interface
has been deprecated in favor for "build".
I as just about to write "So, while this might be one road to go, this
is not of much use for us yet.". Anyhow, this might be a good base for
pep517 based packages. On the other hand: Maybe we'd better stick with
"pip wheel" and "pip install", see above.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goebel@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |