Consider putting PATH modification to ~/.config/environment.d on Linux platforms

[ghost]

Problem you are trying to solve

Rustup currently set-ups the PATH environment variable by having a file in Cargo home to update it and then updates the shell configs to source that file.

This method doesn't work on all shells (fish for example) and doesn't work when a program isn't started from shell.

Solution you'd like

There is a FreeDesktop specification for setting environment variables: https://www.freedesktop.org/software/systemd/man/environment.d.html.

By putting the PATH set-up, it will be set-up on login and working no matter the shell or if the program was executed from the shell.

Notes

Disadvantage is that this doesn't work on Linux systems not using systemd or with systemd-environment-d-generator disabled (this isn't a common case though, is default even on Arch Linux).

[rbtcollins]

Thats an interesting idea. @workingjubilee spent a chunk of time on the PATH shell setup a while back and didn't find that specification. How long has that specification been a thing? Does it, for instance, work with common LTS versions of distros like Ubuntu 18.04 ?

[ghost]

The generator seems to be present in Ubuntu 18.04 as it's included in the systemd package, but I haven't tried it personally.

[workingjubilee]

Notes

Disadvantage is that this doesn't work on Linux systems not using systemd

That feels like it makes it a bit of a non-starter, then? It is very common to use rustup in combination with e.g. AlpineLinux which uses OpenRC, and in the modal case where rustup is used "out of the box" instead of e.g. repackaged as a system package, it is a nice property that you can uproot your entire home drive and reinstall it on another Linux and have rustup immediately start working again.

Mind, I'd be willing to sacrifice the "nice property" if the solution was not systemd-dependent.

[workingjubilee]

Also:

This method doesn't work on all shells (fish for example) and doesn't work when a program isn't started from shell.

The redesign was implemented this way specifically so that, despite bugs or weirdly-patched behavior in things like gnome-session and most Wayland implementations, it would be handled in the event that an individual program isn't booted from the shell, because it would have been done in the previous startup phases, as those would go through a login shell in order to boot the GUI. Please open a separate bug if you actually use a configuration where this is proven false.

I am aware that it doesn't quite work for fish. Fish is an oddball where it has its own quite beautiful solution for PATH handling... that is completely at odds with how everything else works.

[ghost]

An option would be to perform detection if system is using systemd and use that, to provide a solution at least for systemd users.

[workingjubilee]

I suppose that may be sensible even though it may not satisfy

, it is a nice property that you can uproot your entire home drive and reinstall it on another Linux and have rustup immediately start working again.

but I am curious about

and doesn't work when a program isn't started from shell.

What distro did you encounter this phenomenon on, or was that a hypothetical? In practice, the reason the current solution tends to work despite this is that usually a login shell has been executed by the time we get to e.g. a desktop.

[workingjubilee]

I should also note that this doesn't work on WSL, as WSL simply doesn't have systemd Wait, ignore that, it does now.

[djc]

Going to close this as a duplicate of #247.