poetry Build System

[darthtrevino]

Hey Raul,
I wanted to make some contributions around the issues I've been posting. As a first step I thought I'd offer up a build-system update.

This PR updates semversioner with the Poetry build system, which is a PEP517-based package management tool.

The tasks in the makefile have been replaced with poethepoet tasks. These can be invoked via:

poetry run poe lint
poetry run poe test
poetry run poe clean
# this will run semversioner release, generate a changelog, and update pyproject.toml
poetry run poe release 

# additional parameters can be passed in as well, e.g.
poetry run poe test --junitxml=tests.xml

The release flow is also a little different. The publish script assumes that you're got a PyPi Trusted Publisher configured, which means you don't need $TWINE_USERNAME and $TWINE_PASSWORD. It also expects that developers have run poetry run poe release in a release branch.

If you'd like to use this, I'd be glad to help with any configuration issues you run into.

Thanks!
Chris

[raulgomis]

Hi @darthtrevino ,

Thanks for your contribution. I like the idea of moving to Poetry as well as setting up PyPi Trusted Publisher. Let's work on the details to make this merged.

Cheers!
Raul

[raulgomis]

In order to automatically bump versions, this should not be hardcoded or manually updated. It should be read from __version__.py.

[darthtrevino]

Hmm, that may be an incompatible goal with how Poetry works

[darthtrevino]

I agree that there should be a single source of truth here, but I kind of think it should go the other way.
 
We could model this as a build step that reads from pyproject.toml and injects that version into init.py.

Another route we could go is use the poetry-dynamic-versioning plugin to hydrate the version in pyproject.toml and in version.py the closest git tag, which is what I used recently in this project (https://github.com/graspologic-org/graspologic).

[raulgomis]

Yes, makes sense. We could update both places during the build process: https://github.com/raulgomis/semversioner/blob/master/.github/workflows/build-and-publish.yml#L60 and have an additional check to verify both versions are the same before publishing to avoid any mismatch.

This is an interesting thread with similar (and additional) ideas: python-poetry/poetry#144 (comment) .

Thoughts?

[raulgomis]

@darthtrevino I'll find some time this week to run this in local and test this branch for additional feedback. Thanks for your contribution.

[raulgomis]

It is possible to use poetry publish here instead of relying on the github action?

[raulgomis]

I'm not an expert on Github Actions as I normally use other CI/CD tools, but I'd like to find a way that we build only once, and deploy exactly the same artifact we run the tests against. From what I understand from this workflow is that we are building it again, pulling dependencies, etc. The poetry.lock file helps reducing the risk to introducting non tested behaviour, but overall I'd like to have a CI/CD workflow that enforces:

After merging to master:

• We run tests
• We package only once
• We publish the package we run the tests against

Does it make sense? I'll read a bit more about how to achieve that in actions.

[raulgomis]

Yes, makes sense. We could update both places during the build process: https://github.com/raulgomis/semversioner/blob/master/.github/workflows/build-and-publish.yml#L60 and have an additional check to verify both versions are the same before publishing to avoid any mismatch.

This is an interesting thread with similar (and additional) ideas: python-poetry/poetry#144 (comment) .

Thoughts?