-
Notifications
You must be signed in to change notification settings - Fork 23
Move from setup.py to uv+pyproject.toml #496
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
base: main
Are you sure you want to change the base?
Conversation
|
Skipped: This PR changes more files than the configured file change limit: ( |
|
Just realized I need to update the release workflow as well. Don't merge before I do that (should only take a moment or two) |
b5af0ef to
ffcc2a3
Compare
|
The release workflow has been updated now, and according to the UV docs the way we should go about authentication for publishing a package is to configure this release action as a trusted publisher on PyPI. I can only make part of that process happen, namely, I can follow the guide for creating the release workflow, including the recommended environment (which I did in ffcc2a3). The rest will, I'm sure, need to be discussed or acted on by someone else (@nicknisi maybe?). |
ffcc2a3 to
76de821
Compare
76de821 to
0b71da4
Compare
Previously, we were using setuptools via a setup.py file and various requirements*.txt files. This updates the package to the more modern pyproject.toml file and switches our build system to uv. Additionally, the package was previously a top level package, which improves testability since the package will no longer be automatically added to sys.path. This change will improve both our developer experience and the packages reproducibility.
0b71da4 to
96a728f
Compare
96a728f to
1095440
Compare
Description
I ran this by @nicknisi, but this is an upgrade to the plumbing behind our package building a testing to use UV instead of
setup.py."Why?" I hear you asking; ultimately a few reasons.
setup.pyfile and direct invocation, but all direct invocations ofsetup.pyhave been essentially deprecated for years, and since PEP 518/621 landed, it's preferred to move away from the file entirely towards non-code files (namely,pyproject.toml).src/layout (i.e. the python package is in thesrcdirectory instead of therootdirectory) and managing its installation withuvalso means we avoid some common and easy to hit bugs when it comes to catching import problems etc.There are other reasons I could probably elucidate, but I genuinely think this is a fairly uncontroversial change since a lot of the Python community is running to use UV as it stands.
Importantly, this does not change user workflows at all, with the minor exception of affecting those who were executing
python setup.py installdirectly previously (I'm unclear if there's a way to know that up front. We can bump the version and communicate this as a breaking change if so).Documentation
Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.
If yes, link a related docs PR and add a docs maintainer as a reviewer. Their approval is required.