Skip to content
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

Merged
merged 9 commits into from
Feb 9, 2022
Merged

Conversation

DMRobertson
Copy link
Contributor

@DMRobertson DMRobertson commented Jan 26, 2022

  1. Use poetry rather than setuptools to define the package.
  2. Use workflows in backend-meta and the setup-python-poetry action to use poetry in CI.

Copy link
Contributor

@reivilibre reivilibre left a 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
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

David Robertson added 3 commits February 8, 2022 16:26
I've also moved the changelog checks into the same yaml file, though
that doesn't really interact with poetry.
@DMRobertson DMRobertson changed the title Dmr/poetry Pin dependencies with poetry, and use this in CI Feb 8, 2022
@DMRobertson DMRobertson marked this pull request as ready for review February 8, 2022 16:46
@DMRobertson DMRobertson requested a review from a team as a code owner February 8, 2022 16:46
@DMRobertson
Copy link
Contributor Author

I need to update this with a description of the diff between wheels and sdists before and after poetry.

@DMRobertson
Copy link
Contributor Author

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.

sdist.diff.txt
wheel.diff.txt

In the sdist:

  • no more MANIFEST.in, matrix_sydent.egg-info
  • poetry includes matrix_is_test, scripts, scripts-dev, matrix-sydent.service, pyproject.toml,
  • poetry generates a PKG-INFO and setup.py with more metadata
  • poetry includes an openmarket change because that branch doesn't have a489866

In the wheel:

  • poetry does NOT include matrix_is_test
  • poetry generates a slightly more complete METADATA file
  • poetry's RECORD file is slightly different: entries are sorted alphabetically, whereas sydent lists files before subdirectories. Additionally, openmarket.py has a different hash, but that's expected because the poetry branch doesn't have a489866
  • poetry marks itself as the generator of the WHEEL file

So TL;DR there are some slight differences, but I think everything is legitimate.

@reivilibre
Copy link
Contributor

no more MANIFEST.in
I was going to reply:
Somewhat paradoxically-sounding, I would think MANIFEST.in should be included in the sdist.
Python's docs say that it is by default: https://packaging.python.org/en/latest/guides/using-manifest-in/#how-files-are-included-in-an-sdist.

But actually I think you're not even using it anymore; instead configuring the sdist through Poetry. That sounds fine then, since pyproject.toml is included. Will review rest..

Copy link
Contributor

@reivilibre reivilibre left a 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"
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@reivilibre reivilibre left a 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"
Copy link
Contributor

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`
Copy link
Contributor

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 :-)

Copy link
Contributor Author

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.

Comment on lines +8 to +10
black .
flake8
isort .
Copy link
Contributor

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.

Copy link
Contributor Author

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...

Copy link
Contributor Author

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)

@DMRobertson
Copy link
Contributor Author

@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?

@reivilibre
Copy link
Contributor

yep, looks like a decent CI output layout! @DMRobertson

@DMRobertson DMRobertson merged commit f42a651 into main Feb 9, 2022
@DMRobertson DMRobertson deleted the dmr/poetry branch February 9, 2022 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants