Store Python toolchains under XDG directory on macOS

[baggiponte]

Hey there! Thanks for the amazing work. Using uv preview features and love it.

I noticed uv toolchain installs under $HOME/Library/Application Support. How does uv feel about following XDG spec? I saw ruff is doing it. For example, rye installs under $HOME/.local/share.

Also when I do uv toolchain list I get this result:

warning: `uv toolchain list` is experimental and may change without warning.
cpython-3.12.4-macos-aarch64-none       /opt/homebrew/opt/python@3.12/bin/python3.12
cpython-3.12.3-macos-aarch64-none       /Users/luca/Library/Application Support/uv/toolchains/cpython-3.12.3-macos-aarch64-none/install/bin/python3
cpython-3.11.9-macos-aarch64-none       /Users/luca/Library/Application Support/uv/toolchains/cpython-3.11.9-macos-aarch64-none/install/bin/python3
cpython-3.10.14-macos-aarch64-none      /Users/luca/Library/Application Support/uv/toolchains/cpython-3.10.14-macos-aarch64-none/install/bin/python3
cpython-3.9.19-macos-aarch64-none       /Users/luca/Library/Application Support/uv/toolchains/cpython-3.9.19-macos-aarch64-none/install/bin/python3
cpython-3.9.6-macos-aarch64-none        /Library/Developer/CommandLineTools/usr/bin/python3
cpython-3.8.19-macos-aarch64-none       /Users/luca/Library/Application Support/uv/toolchains/cpython-3.8.19-macos-aarch64-none/install/bin/python3

i.e. also Homebrew Python.

(I guess a uv pin or uv local command is coming soon, looking forward to it.)

[zanieb]

We're talking about it e.g. #2236 and #3049 and astral-sh/ruff#10739

I think it's fairly clear that people prefer the XDG directory for configuration on macOS but I'm not sure what to think of application "state" like this.

[zanieb]

Personally I'm pretty interested it's just weird to go against the platform standard and notably our cache is also not using the XDG directory on macOS.

[baggiponte]

Thanks for the prompt reply! As far as Python interpreter discovery, what do you plan to support? Anyway, feel free to close this 😊

[zanieb]

I'm happy to leave it open to gauge interest. Maybe we need a special toggle.

Python interpreter discovery is a whole thing :) I don't think we should chat about it in the issue, but you could take a look at the supported sources. #4198 will address your question about the system interpreters being listed.

[dsully]

+1 for ~/.local, etc. Effectively treating macOS like Linux in this regard.

[hoechenberger]

Just chiming in here to say that I'd rather keep the current behavior. XDG is not relevant for macOS and I'd like uv to follow the platform's standards, not those of a Linux system. That said, I have not yet read any of the referenced issues / discussions.

[baggiponte]

Just chiming in here to say that I'd rather keep the current behavior. XDG is not relevant for macOS and I'd like uv to follow the platform's standards, not those of a Linux system. That said, I have not yet read any of the referenced issues / discussions.

I see your point, but there are already plenty of programs that, if XDG_* vars are set on macos, will comply with that. It's handy because as a developer it improves the way I manage things (dotfiles, knowing where to go when I need to free up ram...). I don't remember how it ended up there, but there are a bunch of jetbrains stuff under my ~/.local/share too.

It's also fair to say there are plenty of programs that don't care. VSCode, for example, slams everything under $HOME, IIRC plugins included.

EDIT: My point is: it feels it's more of a standard for GUIs/Applications than programs.

[hoechenberger]

@baggiponte I absolutely agree that many programs don't respect the OS conventions 😃 When developing Python packages, for example, I therefore make use of platformdirs, which automatically does "the right thing" when it comes to figuring out where to store config files, temporary data etc. I'd argue it's good practice to follow this approach ... I'm not looking to start a fight over this :) just wanted to share my opinion.

best wishes!
Richard

[dsully]

To be clear - as long as the $XDG_* variables are respected as @baggiponte says, I'm good with that approach.

[hoechenberger]

Ah! Got you! Yes this does make sense.

[charliermarsh]

For context, we do use XDG for configuration file discovery so there's some precedent there.

[zanieb]

Another datapoint is that pipx uses the XDG spec for storing installed tools.

[baggiponte]

Another datapoint is that pipx uses the XDG spec for storing installed tools.

Speaking of, tools that are installed with uv tool install will have to be added to $PATH somehow. I don't think I ever saw adding $HOME/Library/Application Support/uv/ to $PATH. IIRC, rye prompts you to use shims.

[zanieb]

Tool installation places binaries entry points according to the XDG specification on all platforms

uv/crates/uv-tool/src/lib.rs

Lines 264 to 275 in 13b0beb

	/// Find a directory to place executables in.
	///
	/// This follows, in order:
	///
	/// - `$XDG_BIN_HOME`
	/// - `$XDG_DATA_HOME/../bin`
	/// - `$HOME/.local/bin`
	///
	/// On all platforms.
	///
	/// Errors if a directory cannot be found.
	pub fn find_executable_directory() -> Result<PathBuf, Error> {

But that doesn't mean we need to place the virtual environment there.

Regardless, I'm leaning towards switching to XDG entirely on macOS.

[charliermarsh]

@zanieb - We still may need something like pipx ensurepath for all this stuff though -- it's not guaranteed that they're on the user PATH IIUC.

[zanieb]

Yeah of course — that's described in #3560 but I'll create a specific issue.

edit: We should at least do #4671

[zanieb]

I've opened a pull request to support the variable if set #4769