Use poetry instead of pipenv for developer/testing #3214
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR removes the (defunct) pipenv setup, which was not maintained and did not pass the tests. Instead of using requirements.txt and requirements-dev.txt, it switches to use poetry https://python-poetry.org
Installation of the flair library continues to not require poetry, it can still be installed directly via pip as before, so for flair users this change should be transparent. For the development/testing dependencies to be installed, poetry is required.
In this PR it was decided to not include the poetry.lock file, allowing the CI/CD to find the most recent legal package versions each time. This took 3 min 18s just now on the github runner. This slows down the pipeline and the first poetry install of a new developer. Alternatively we could commit the poetry.lock file, but would have to remember to do "poetry update" from time to time manually, to allow the CI/CD pipeline and the developer setups to update as new versions are released.Update 1:
After some thinking on it, I have added poetry.lock to be commited. The main downside is that there is some work involved for developers/contributors to occasionally run "poetry update", but the advantage is that the pipeline and new developer setup is faster, and that the pipeline will be more predictable (not failing because a new version introduces a issue) and that it also solves the inconsistency/version-drift issue between pre-commit hooks package versions and versions installed in the main environment:The exact same versions can be pinned in poetry.lock and .pre-commit-config.yaml - this could (should!) then also be enforced by CI.
Update 2: Since it was decided to remove pre-commit entirely the case for using the poetry.lock in CI/CD is weaker again, so I have added "poetry lock" for each pipeline run back again. Note that I did leave the poetry.lock checked in, allowing new developers to start quicker.