[Breaking] Install in ~/.local/bin instead of cargo home

[konstin]

uv is not part of the rust toolchain nor is it usually installed or managed by cargo. Similarly, i expect that the majority of users does not have cargo installed. We should instead use a not-rust-associated directory for binaries.

I chose ~/.local/bin, which is mentioned in XDG Base Directory Specification and also used by pipx.

User-specific executable files may be stored in $HOME/.local/bin. Distributions should ensure this directory shows up in the UNIX $PATH environment variable, at an appropriate place.

As testing strategy, i'd create a prerelease and test windows and linux(es), while i'd need someone to test mac.

[charliermarsh]

How does this work across platforms? Like what happens on Windows?

[konstin]

Windows currently uses C:\Users\Ferris\.cargo\bin, i expect this to switch to C:\Users\Ferris\.local\bin.

[charliermarsh]

For what it's worth, I don't have a ~\.local\bin on my Windows machine, but it does look like pipx uses that. Will the installer add it to PATH?

[charliermarsh]

I'm cool with the directory but will it cause problems when used alongside pipx?

[charliermarsh]

Should it be ~/.astral/bin...?

[konstin]

Should it be ~/.astral/bin...?

If everybody did that it would require a PATH entry per vendor, which imo would be bad. Normally installing into ~/.astral and symlinking into PATH would be an option, but that doesn't work on windows. I could see installing it into ~/.cargo-dist/bin or ~/.axo/bin if that helps with the updater. Note that i'm not opposed to putting stuff into $XDG_*/astral - we should do that - i'm only advocating for this PATH convention.

[konstin]

I've realized this will break people who rely on the current installation location. I'd bundle this with other bigger changes (v0.2 probably) if possible.

[charliermarsh]

Yeah I think this has some upside but also has the potential to be pretty disruptive.

[woutervh]

I don't care whatever default location is choosen, as long as you can choose to override it yourself.
see #2087

My personal preference is ~/bin because I don't want executables hidden away in hidden folders multiple levels deep.
Why?

If I need to support non technical people on windows with a non-working python-executable in some virtualenv,
I would often need to start explaining them to "Open File Explorer from the taskbar. Select View > Options > Change folder and search options. Select the View tab and, in Advanced settings, select Show hidden files, folders, and drives and OK." Just to be able to start seeing a folder.

~/.local/bin is just another personal preference. In 20 years I only encountered a handful installers that use it. i never actively used pipx. It's OK as a default.

[sondr3]

Just chiming in to say that I dislike tools that don't use XDG directories for caches, binaries and configs, they are a standard for a reason. ~/.local/bin is not personal preference, it's where binaries should be installed on Linux (and macOS). My config.fish is littered with directory checks to add binaries to my $PATH for umpteen tools and languages. The same issue in cargo is one of the issues with the most upvotes. ghcup (rustup for Haskell) solves this by symlinking binaries into ~/.local/bin from it's own ~/.ghcup/bin which could be a alternative solution? This way the old setup keeps working but for new users you don't need to check and add a new path to your machine.

[mitsuhiko]

For what it's worth with rye i went through various different choices and I ended up with one path for all platforms instead of messing with the XDG stuff or trying to find suitable locations on all platforms. It's super confusing when you need to look into different places depending on which machine you are on. I also with with ~/.rye/shims as a place on the path since rye is installing further tools. I fully expect that a future uv will be in the same position and will need to bring it's own folder onto the path.

[konstin]

@woutervh Is .local a hidden folder for you on windows? It looks non-hidden on mine.

@mitsuhiko What made you choose that over .local/bin?

[woutervh]

Rye is a good example: via RYE_HOME, a user can still override the default directory and choose their own location
(and I use it, many thanks @mitsuhiko)

@konstin .dotfiles are not hidden on windows? You are right, my mistake.

Just chiming in to say that I dislike tools that don't use XDG directories for caches, binaries and configs,
For system-managed applications I agree, but for virtualenv-based tools even XDG should only be a default that can be overridden.

the goal of using venv is isolation from other venvs,
then imagine a venv-based tool insisting taking its config from the hardcoded location:

• venv-app-v1/bin/app
• venv-app-v2/bin/app
• venv-app-v3/bin/app

all reading ~/config//config

[mitsuhiko]

@mitsuhiko What made you choose that over .local/bin?

rye tools install installs additional binaries. Those need to be placed somewhere. If I were to put them into ~/.local/bin I would start to muck around in a folder that is not fully under rye's control. Similar motivation to ~/.cargo/bin I assume.

[konstin]

What would you think about (sym)linking those binaries to ~/.local/bin, from the background that it's the XDG standard that users are expected to have in PATH while rye's shim directory requires modifying dotfiles?

[zanieb]

We might want to take into account toolchain management design considerations e.g. rustup / cargo do not have shims in ~/.local/bin.

[konstin]

For me it comes down to a somewhat philosophical distinction: Do we consider uv a tool that gets installed, so it goes where all the installed tools go, or do we consider it a "system" application manager with its own domain that can reasonably expect people to change their PATH for it. Note that people have asking cargo to use the xdg directories.

[alldevic]

In Windows, why not use %APPDATA% folder for specific user and Program Files for everyone?

[zanieb]

I think we should change this someday still

[konstin]

I'm also strongly in favor of getting out of the cargo brand. If we want to change it, i believe we need to do it in breaking release before uv tool support lands, the sooner the better before external dependencies on the uv install location are created.

[zanieb]

@charliermarsh Why were you opposed to doing it in 0.2.0?

[charliermarsh]

I just didn't consider it an important change and hadn't had time to think through the consequences. How will this interact with tool installs? Do we know?

[charliermarsh]

By "important", I mean "pressing" or "time-sensitive".

[zanieb]

I don't see how it interacts with tool installs. I agree it's not pressing but I agree with Konsti that there is some time sensitivity in that the longer we wait there may be increased reliance on this install location downstream.

[charliermarsh]

The interaction point is: where will binaries installed by uv be placed?

[zanieb]

True that's a consideration and an open question.