Add setting to manage preference for managed toolchains #4198
Comments
|
We could also frame this differently, like.. |
What about? Or you could explicitly configure python providers like PDM. People might (and are) using tools like mise asdf pyenv. |
|
What's the difference between I don't think we'll support discovery of Python interpreters in other tool's installation directories. It seems more reasonable to just expect them to be registered in the PATH (or, on WIndows, in the registry). |
) Adds support for the toolchain discovery preferences outlined in #4198 but we don't expose this to users yet, I'll do that next to make it easier to review. I've made some refactors in the toolchain discovery implementation to enable this behavior and move us towards clearer abstractions. There's still remaining work here, but I'd prefer tackle things in follow-ups instead of expanding this pull request. I plan on opening a couple before merging this. I'd like to shift the public toolchain API to focus on discovering either an **environment** or a **toolchain**. The first would be used by commands that operate on an environment, while the latter would be used by commands that just need an interpreter to create environments. I haven't changed this here, but some of the refactors are in preparation for supporting this idea. In brief: - We now allow different ordering of installed toolchain discovery based on a `ToolchainPreference` type. This is the type we will expose to users. - `SystemPython` was changed into an `EnvironmentPreference` which is used to determine if we should prefer virtual or system Python environments. - We drop the whole `ToolchainSources` selection concept, it was confusing and the error messages from it were awkward. Most of the functionality is now captured by the preference enums, but you can't do things like "only find a toolchain from the parent interpreter" as easily anymore.
Makes sense, but then I guess what's the difference between |
|
A "system" Python here is any Python toolchain installed on the system i.e. not being managed by uv. Brew Python will come up if it's on the PATH, but we won't try to discover it a Brew-specific location (as we won't, thusfar, attempt to discover |
|
It would be useful to be able to tell uv to prefer using asdf/pyenv discovery/installation if that's available rather than only python-build-standalone |
|
This issue is actually completed: https://docs.astral.sh/uv/reference/settings/#python-preference Feel free to open a new one to track support for other managed Python distribution kinds, but we're pretty unlikely to support more. |
|
sure, done #7400 Thanks! |
Users should be able to opt in and out of managed toolchains, e.g.
The text was updated successfully, but these errors were encountered: