Migrate project setup to poetry

[Nicoretti]

fixes #103

[littleK0i]

Btw, is there any reason to use poetry specifically?

A simple Python build seems to be much shorter and easier to manage.

Recently I've migrated an another project to build. This is how it looks:

• https://github.com/littleK0i/SnowDDL/blob/master/setup.cfg
• https://github.com/littleK0i/SnowDDL/blob/master/pyproject.toml

Easy & clean. No issues so far.

https://pypi.org/project/build/

[Nicoretti]

Hi @littleK0i,

Thanks for asking; I'll try to give you some background.

Btw, is there any reason to use poetry specifically?

Context

The Exasol Integration-Team maintains a significant number of Python projects/repositories. In order to keep the automation and context switching overhead smaller, we started to harmonize the projects and their "basic" infrastructure regarding setup, build, testing, etc.

If you have a look at our toolbox and its design document, you may get a rough idea. Still, this effort is a work in progress and is being done alongside the regular project work, so there is quite some way to go.

If you dig into the git history of styleguide, you should be able to find the "initial" list of tools and libraries we intended to use. Maybe even some rationale (but not sure if that ever made it into the repository). Developing the tooling and making changes along the way in the projects has shown to be a more efficient (lightweight) process to go for.

Why did we choose poetry?

• Good dependency resolver
• Integration of dependency locking
• Integration of virtual environments as part of the workflow
• The devs already knew poetry (pros and cons)
• Poetry was already used in a significant number of Python projects
• Changing the build (project management) for "all Python" projects is very costly

Personal Note

build looks quite interesting. I personally will definitely give it a try. In turn you may also find this projects interesting:

• Flit
• Hatch

Unfortunately, I personally didn't find a PEP-621/518-compliant build & project management system that checks all my boxes yet.

best Nico

[littleK0i]

Thank you for detailed explanation. You mentioned some good reasons, so it's not a problem.

My final concern is poetry.lock file. I suspect, it attempts to "lock" dependencies, which may cause issues if end user is not prepared for that.

For example, this file lists pandas==2.0.2 which requires Python 3.8+, but what if end user has Python 3.7?

Since I did not use poetry before, I am not sure what might happen with existing users using older versions of dependencies.

[Nicoretti]

My final concern is poetry.lock file. I suspect, it attempts to "lock" dependencies, which may cause issues if end user is not prepared for that.

For example, this file lists pandas==2.0.2 which requires Python 3.8+, but what if end user has Python 3.7?

Since I did not use poetry before, I am not sure what might happen with existing users using older versions of dependencies.

@littleK0i sure that is a legit concern, let me try to bring some light into this.

TL;DR: Library/Package users will be fine, it is rather for development and having reproducible builds/workspaces.

Details

I don't think I can do a much better job than the poetry documentation explaining the .lock file and it's semantics. This is why I would suggest you to have a quick look over there (the docs are quite concise).

Still I can add this "practical" approach: If you run poetry build and inspect the generated METADA (wheel) or setup.py (src-dist) you will see that those only obey the constraints from the pyproject.toml file.

Note:

The Poetry documentation regarding lock files "As a library developer" basically describes what we are using it for (most of the times).

Side note regarding Python 3.7:

I think Python 3.7 support can be dropped, due to the fact that it will be unmaintained in 4 days anyway.