Switch to poetry

[reckart]

Describe the refactoring action Switch to poetry and pyproject.toml.

Expected benefit Align with pycaprio and I kind of like the declarative nature of pyproject.toml vs the setup.py.

[DavidHuebner]

Aside from personal preference, do you see any advantages of using poetry over plain pip? Why not align pycaprio with dkpro-cassis by using a pip-variant everywhere?

In my experience, poetry is useful for larger projects, but has a little more overhead whereas pip is faster to set up and more suited for small projects like this one.

[reckart]

I prefer a declarative approach to the build like it is provided by pyproject.toml versus the programmatic approach adopted by setup.py.

I have briefly tried using pyproject.toml with setuptools as the build system, but it does not automatically pin down the versions (i.e. it does not create a requirements.txt or similar file like a poetry.lock that would ensure that builds always use the same dependency graph).

[DavidHuebner]

Yes, locking down the dependency graph is probably the biggest advantage of poetry.

Personally, I think that the installation of poetry itself (see https://python-poetry.org/docs/#installation) is a little more complicated and poetry itself is a bit more unfamiliar to some Python developers compared to plain pip / venv.

However, this shouldn't block you if you think it is a good decision to switch to poetry.

We will need to pay special attention to adjusting the Github actions to Poetry as they are not tested automatically (especially the release build).

[reckart]

So far, all I had to do was pip install poetry. At least locally, I never work without venvs. With the GH actions, I didn't have trouble with PyCaprio either.

[DavidHuebner]

On the link that I posted above, it says:

Poetry should always be installed in a dedicated virtual environment to isolate it from the rest of your system. It should in no case be installed in the environment of the project that is to be managed by Poetry. This ensures that Poetry’s own dependencies will not be accidentally upgraded or uninstalled. (Each of the following installation methods ensures that Poetry is installed into an isolated environment.) In addition, the isolated virtual environment in which poetry is installed should not be activated for running poetry commands.

So you will need to use a second virtual environment to manage poetry itself.

[reckart]

So you will need to use a second virtual environment to manage poetry itself.

Meh... 👎 😐

Are there sensible alternatives to setuptools and poetry that could be considered? Or is there a way to have setuptools lock down the dependency graph?

[DavidHuebner]

There is a library called pip-tools which brings pip-compile that creates a requirements.txt from requirements.in, pyproject.toml or setup.cfg or setup.py. This requirements.txt then contains the locked down versions and is used by the installers. See: https://pip-tools.readthedocs.io/en/latest/cli/pip-compile/

Again, I am not sure if this is actually required for a small project with rather limited dependencies.