-
Notifications
You must be signed in to change notification settings - Fork 33
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
QA: mypy, reformatting, and linting #69
Conversation
More misc cleanup.
Went ahead and added a publishing workflow as well: ecbe369. |
- name: publish | ||
uses: pypa/gh-action-pypi-publish@v1.8.6 | ||
|
||
- name: sign |
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 am not familiar with this step yet, but we sign after we've published to PyPI?
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.
Yep, for the moment -- PyPI doesn't support these signatures (yet) and the action writes to the same input directory, so doing it before the publishing step confuses the bejeezus out of the underlying twine upload dist/*
invocation.
Happy to refactor, though, if you'd prefer -- this is primarily laziness on my part (and it's what I do on other projects for the time being) 🙂
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.
No need for a refactor - I was curious as to the order of operations.
However, now that you've mentioned twine, it makes me inquire "why use flit at all" if the gh-action responsbile for the publish part is already using twine, and flit's primary purpose is to:
Flit is a simple way to put Python packages and modules on PyPI.
If we're not using it for its primary function, should we continue to use 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.
I've been using it for its PEP 517 build backend, out of muscle memory -- IIRC I chose it years ago because it had a mature 517 backend at a time when setuptools' own backend was still a work in progress.
(I actually had no idea it also supported publishing -- I thought its primary function was to be a packaging backend a la setuptools
or hatch
.)
IMO we should continue to use it unless we have a compelling security or performance reason not to -- switching to another 517 backend would involve a small amount of pyproject.toml
churn for no discernible change in output 🙂
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 actually had no idea [Fl]it also supported publishing -- I thought its primary function was to be a packaging backend a la setuptools or hatch.
Nowadays that's probably its main function, but it predates PEP 517, and I wanted to be able to build packages and publish them with one command. And so far the upload functionality hasn't been all that much effort to maintain (although I'm just now working on better support for using tokens to do uploads).
This runs the configured formatting and linting tools over the codebase and checks the results in.
It also adds a reasonably strict set of
mypy
settings, type hints, and apy.typed
marker for downstream consumers.