-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Update build system to flit_core #103
Conversation
Hi @takluyver, thank you for your PR, it's really appreciated! I haven't used spyrmsd/.github/workflows/pypi.yml Lines 23 to 30 in d50f203
stopped working, and because the software is somewhat stable and I haven't done any release. In #54 I tracked the issues I had with Two things before merging:
|
|
Thanks! And sorry Flit didn't work smoothly for you. This change doesn't need a change to your CI action, but PyPI now requires two-factor authentication, so uploading with a username & password doesn't work any longer (unless you've already configured a token in place of the 'password' - naturally I can't see this). There's a new & fancy way to automate releasing from Github, though: you can tell PyPI to trust this Github repo, and then use the pypi-publish action on Github. This handles authenticating to PyPI, so you no longer need to configure a secret manually. |
I've added this to the changelog. I'd feel like a fraud adding myself to the citation for a tiny mechanistic change (I don't even know what 'symmetry-corrected RMSD' means 😉 ), so I'll leave 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.
Thank you @takluyver!
Looks like removing versioner allowed to successfully deploy again using |
Great! 😃 |
Hi, I'm opening this pull request as part of a push to modernise how packages use Flit as a Python build backend.
Using
flit_core
as the backend in place offlit
is recommended in the docs, and will make it faster for tools like pip & build to build your package from source, as it has fewer dependencies to install.Specifying an explicit version range (
>=2,<4
) helps to ensure that your package can still be readily built from source despite changes in future major versions of Flit, because it will still use version 3.x. For instance, a future version is likely to drop support for the[tool.flit.metadata]
table, in favour of the now-standardised[project]
table for metadata. This is also in the docs, along with details of which versions support which features.Most users probably install your package from a pre-built 'wheel' on PyPI, so this changes won't affect them at all. But people who install from a git checkout, for instance, will benefit.