Use poetry for packaging

[sjagoe]

Part one of addressing #196

[itziakos]

I am not sold on poetry but I can see the appeal. On thing that bugs me is that one needs poetry packages to build the package from the sdist. Is there a way that the generated sdist uses just setuptools without any dynamic features?

[itziakos]

Do we really need to be so strict in the runtime dependencies? Stevedore is stable enough and I think it is safe to have ">=4.1.1"

[itziakos]

FYI, locally I build haas using stevedore 5.x

[sjagoe]

It's typical in application development to pin dependencies to semantic-version compatible. I'm open to either. Or to adding v5 as the version used for later python versions.

[sjagoe]

I am not sold on poetry

What options do we have that satisfy these requirements?

1. Use pyproject.toml exclusively (with plugin entry points as well)
2. Support generating the version number from git and writing it to the source

I didn't look at many, but chose poetry for its metadata format being more pleasant to use than hatchling

[sjagoe]

Okay, I'm not up-to-date on new setuptools. The only think I see missing I think is the dynamic version number, but otherwise we could use that instead of poetry. Although I kind of like poetry for the reason of it managing the virtualenv for me

[sjagoe]

I don't see a way for using pyproject.toml for development dependencies with setuptools. It looks like going that way would lead back to a mix of different dependency management solutions (requirements files for some subset) rather than defining all project metadata in pyproject.toml.

To me poetry is the clearly more complete solution.

[itziakos]

@sjagoe the PR is ok as we discussed offline.

[sjagoe]

I made some changes to open up dependency versions and remove the poetry lock file.

[sjagoe]

Closed in favour of #199