-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pin dependencies with poetry, and use this in CI #488
Conversation
DMRobertson
commented
Jan 26, 2022
•
edited
Loading
edited
- Use poetry rather than setuptools to define the package.
- Use workflows in backend-meta and the setup-python-poetry action to use poetry in CI.
ef4c815
to
25cf1e3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems pretty reasonable otherwise, but it's still a draft so I won't poke further
@@ -1,17 +0,0 @@ | |||
name: Changelog |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a particular reason for coalescing all the pipelines into one? I quite liked the separation because it means there's much less GHA YAML to grok at once when you have to come and mess with it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes and no. Having stuff in one file (e.g. by using a matrix
strategy
) can help reduce duplication. I'm trying to prevent one file/project having an outdated bit of config where possible. I did deliberately lump the linting into one reusable action so that there's less yaml duplicated between projects.
No hard and fast rules here though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, and AFAIK it's easiest to make one piece of CI conditional on another piece of CI when they're defined in the same file.
I've also moved the changelog checks into the same yaml file, though that doesn't really interact with poetry.
1e7ff44
to
e9e1b7d
Compare
I need to update this with a description of the diff between wheels and sdists before and after poetry. |
These are a diff from a489866 to e9e1b7d. In the sdist:
In the wheel:
So TL;DR there are some slight differences, but I think everything is legitimate. |
But actually I think you're not even using it anymore; instead configuring the sdist through Poetry. That sounds fine then, since |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but any chance you can provide updated instructions for contributing (and for developing... I've never touched poetry! :)).
Do the instructions in https://github.com/matrix-org/sydent/blob/main/CONTRIBUTING.md still work? I would guess not from what I've heard.
- run: "scripts-dev/check_newsfragment.sh ${{ github.event.number }}" | ||
|
||
common-python-ci: | ||
uses: "matrix-org/backend-meta/.github/workflows/python-poetry-ci.yml@v1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the semantics of @v1
here — is that fixed to a literal git tag, or something smarter?
If so, to update it, do we have to come back here and replace it with @v2
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the semantics of
@v1
here — is that fixed to a literal git tag, or something smarter?
Literal git tag, branch name or SHA hash.
If so, to update it, do we have to come back here and replace it with
@v2
?
GHA's advice on versioning is here. (That's for a custom action rather than a reusable workflow, but I think the advice is worth following here too.) TL;DR:
- use semver
- tag each released version as vMAJOR.MINOR.PATCH.
- maintain a major version tag vMAJOR.
- if you make a MINOR or PATCH release, move the major version tag to point to the latest release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you make a MINOR or PATCH release, move the major version tag to point to the latest release.
Aha, I see — I seem to remember it being bad karma to change a tag but I suppose if it's for an action where this is the guideline, it's fine, I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. I think it needs a --force
to actually move the tag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
woots
- run: "scripts-dev/check_newsfragment.sh ${{ github.event.number }}" | ||
|
||
common-python-ci: | ||
uses: "matrix-org/backend-meta/.github/workflows/python-poetry-ci.yml@v1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you make a MINOR or PATCH release, move the major version tag to point to the latest release.
Aha, I see — I seem to remember it being bad karma to change a tag but I suppose if it's for an action where this is the guideline, it's fine, I think.
|
||
When you're done, you can close your terminal. | ||
|
||
### Optional: `direnv` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
big thanks for this one; my first question was going to be 'bu-bu-but my direnv workflow!!' but you even thought of that :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've found it works pretty well once you have a poetry definition setup.
black . | ||
flake8 | ||
isort . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How smart are the .
parameters to these — will they descend into ignored dirs etc?
I suppose there's no longer such a question as 'will it descend into venvs' because Poetry venvs are somewhere else?
Happy to roll with this, after all.. don't mind me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can ask poetry to use an existing virtualenv or to create one in a specific location.
How smart are the . parameters to these — will they descend into ignored dirs etc?
black --verbose
skips .gitignored directories. To be honest, I haven't tried the rest recently but I think they did sensible things when I was prototyping this a few weeks back.
'will it descend into venvs'
I did have this problem because one prototype of the setup-poetry action was putting the venv in .venv
in the checkout. Let me double check that's not still the case...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, the poetry venv is in path: /home/runner/.cache/pypoetry/virtualenvs
(from the CI logs)
@reivilibre I've fixed a typo which means that CI actually runs now. Maybe you'd like to have a quick look over the CI output to see if it's to your liking? |
yep, looks like a decent CI output layout! @DMRobertson |