Transition tooling to hatch
#32
Conversation
flake8 does not accept pyproject.toml
| - name: Build | ||
| run: | | ||
| hatch build --clean | ||
| # TODO: Update trusted publishing with pypa/gh-action-pypi-publish |
There was a problem hiding this comment.
I don't mind making the switch to pypa/gh-action-pypi-publish within this PR, since we're already touching this file anyways
EDIT: Looks like there might be a bit that goes into getting that workflow running - We can skip it for now if it's too involved.
There was a problem hiding this comment.
Yes, it would take some work on PyPi (https://docs.pypi.org/trusted-publishers/).
I was thinking to do that in a separate PR, this on was growing enough already! Perhaps doing some updates to create a GitHub release with artifacts, publish, etc, on the creation of a semver tag? Since this uses Keep a Changelog, even that can be pulled out automatically and added to the release
There was a problem hiding this comment.
As an idea of how I suggest updating the actions, I use this flow: https://github.com/stumpylog/gotenberg-client/actions/runs/10653499633
Basically, the checks like tests, documentation and building a wheel/sdist always run, then a release to Github and Pypi run when a tag is created to do those only on a tag. This would also include publishing the versioned documentation.
If that sounds alright, I'm happy to work on it (in a separate PR)
There was a problem hiding this comment.
Unless I'm misunderstanding your comment, that is effectively what is currently being done in this repo but in an event driven fashion rather than polling on each merge.
There was a problem hiding this comment.
You still need to manually create the release, attach artifacts and update the change log right? I don't see anything handling that.
My own preference is to simply push a tag and let the jobs handle that based on what was pushed, and only after that double check of testing, building, etc
There was a problem hiding this comment.
Ahhh okay I understand your point - Yeah manually creating the GH releases is unnecessary manual labor. If we can automate that would be fantastic.
…n checks and update the hooks
There was a problem hiding this comment.
I'm going to push one more nitpick onto this PR before merging.
Since this PR adds additional tooling to the repository, I'd like that to be documented.
I left stubs in the docs to remind myself to create them with the eventual CI overhaul PR - and it looks like that time is now.
It doesn't need to be anything fancy or detailed, but it needs to give the minimum explanation of
- Cloning the repo
- Creating an environment where the tests can run
- Demonstrate how to use the CLI commands that can execute the tests
For example, I was originally planning on using the code.md and docs.md in one of my other repos as a template, but you're free to structure the docs however you'd like.
|
I have taken a stab adding some documentation for both code and documentation, with examples of how to run commands I think will be useful. |
|
There are several spelling errors in the docs according to the tests. |
|
Spelling is always my bane... I think its all resolved now. Once this is good, i can squash it all down (or do it when merging) |
|
New issues created, see |
Description
As an alternative to
noxortox, usehatchto provide both the testing, linting, documentation building, and release building.hatch run lint:checkflake8against the codebasehach fmtwhich usesruff. Wasn't sure if you wanted to keep formatting, etc for ease of merging anything from Whitenoisehatch testhatch test --python 3.10hatch test --python 3.10 --include "django=5.1,4.2"hatch run docs:build- builds the documentation siteCloses #17
Checklist
Please update this checklist as you complete each item:
By submitting this pull request I agree that all contributions comply with this project's open source license(s).