-
Notifications
You must be signed in to change notification settings - Fork 11
Allow configuring the uv version that is downloaded #30
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
Conversation
README.md
Outdated
|
|
||
| The `opts` parameter currently accepts 2 options: | ||
| * `:force` - if true, runs with empty project cache. Defaults to `false`. | ||
| * `:uv_version` - select the version of the uv package manager to use. Defaults to `Pythonx.Uv.default_uv_version()`. |
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.
Same thing here - I wasn't sure if I should reference this or not.
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.
Are we sure we want to nest it under opts? Perhaps just uv_version: ... directly?
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.
Either way works! I was going more in the direction of being able to just send the opts value directly to the functions. If we just use uv_version:... and force:... directly I think I probably just need to change the application.ex to pop the pyproject_toml value from the config and then pass the rest of the config down into the Uv module?
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.
Yeah, that's how i'd do it but let's wait for @jonatanklosko's opinion.
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 definitely prefer it not nested. I also don't think we need :force as a global option, or at least I would wait for a use case and then evaluate other solutions.
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.
Great, will update so that only the uv_version can be set 👍
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.
Updated so that it's explicitly only allowing the uv_version as an option from the compile envs - let me know if this works or if there are any more changes needed here
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 :)
Co-authored-by: Jonatan Kłosko <[email protected]>
Co-authored-by: Jonatan Kłosko <[email protected]>
In the current Pythonx code, the uv package manager's version is hard-coded to a very old version. The uv version not only controls the version of the package manager, but also the managed Python installations which can be used with uv. Since Pythonx enforces using only managed Python versions, this makes it impossible to use versions that have been added in later versions of the uv package manager.
This PR enables the user to set options like which uv version to download, enabling users to change the version based on their needs, and allowing new versions to be downloaded on demand. This is aligned with other packages which pull CLIs from releases like the esbuild and tailwind packages, which enable the user to set the configured version in their config.exs.
In addition to the configuration, I've also updated the default uv version to the latest version as of this date.