Hi Hartmut,
Le 11/09, Hartmut Goebel a écrit : > 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. Neither did I! But things are changing (fast) and it seems that I'm always the last one to know! ^_^' > 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". > > [1] https://packaging.python.org/tutorials/packaging-projects/ > > 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? I cannot say that, at the moment, I'm working in any particular direction! … I'm just trying to make "it" work and learn a bit about Guix packaging and Python along the way. Actually, I'm not even yet sure that Poetry needs a dedicated build system, as it also relies on a build-backend (defined in `pyproject.toml`) which just happened to be `poetry.core.masonry`, but could be another one… I guess, I'm not sure yet. So, definitively a WIP! > > 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. +1! I'll try to make those packages who need a special build system (which might be the case for `keyring`) work and see for a more general "new" `python-build-system` later! And if I happen to learn something on the way… great! :-) Regards -- Tanguy