Re: Packaging Python projects managed with Poetry

[Tanguy Le Carrour <tanguy@bioneland.org>]

Hi Danny,

Thank you for your answer!


Le 10/22, Danny Milosavljevic a écrit :
> On Thu, 22 Oct 2020 17:15:20 +0200
> Tanguy Le Carrour <tanguy@bioneland.org> wrote:
> 
> > does not contain a `setup.py` file –because Poetry does not use it!—, and
> >the `python-build-system` fails.
> > I haven't wrap my head around this yet and I'm not sure what would be
> > the proper way to do it?
> 
> >Write a `python-poetry-build-system`? I hope not!
> 
> Why not?
> 
> According to https://github.com/python-poetry/poetry they took inspiration
> from existing build systems like cargo, and they just replaced setup.py by
> pyproject.toml.
> 
> So what you could do is create a poetry-build-system that is just like
> python-build-system (probably even inherits from it) but uses "poetry"
> instead of "python setup.py".
> 
> If the author of a package replaces the build system used in his actual
> project, he has to expect to also have to replace the build-system reference
> in the guix package.  Why is that weird?

Oh, when I said "hope", I didn't mean to say "weird", but "out of my
comfort zone"! But I guess it would be a good way to learn more about
Guix's internals. So, wouldn't be so bad after all!

I'll give it a try.


> Or you could try to add it to the existing python-build-system--but the
> poetry website doesn't sound like it's designed like that (it rather sounds
> like they want to replace all other python build systems).

Actually, they don't "replace" all other systems, they build on them.
Internally, it uses `pip` and `virtualenv`. And there is competition out
there! To be faire, I should also package `hatch` [1] and `pipenv` [2].
But first, I have to make it right with `poetry`.

[1]: https://github.com/ofek/hatch
[2]: https://pipenv.pypa.io/en/latest


> > Just put the d**n tests in the Python package? This would look like a
> > failure to me! :-(
> 
> If the end user doesn't need the tests, the tests shouldn't make it into the
> derivation of your package.  But they are there while the package is building
> the derivation--so just run the tests then.

And… this is where the end of my comprehension of Guix is reached! ^_^'
The only thing I want to make sure is that the tests don't end up on the
the end user's system, the one that runs `guix install project-managed-with-poetry`.
But I guess the tests (contained in the source) will remain on the builder's system.
At least until they run `guix gc`.

Thanks for your help!

-- 
Tanguy