[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Packaging Python projects managed with Poetry
From: |
Tanguy Le Carrour |
Subject: |
Re: Packaging Python projects managed with Poetry |
Date: |
Fri, 23 Oct 2020 08:27:28 +0200 |
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