Re: Questions regarding Python packaging

[Tanguy Le Carrour]

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