If installing as root use different PATH from ~/.local/bin

[adam-fowler]

In general root users do not have ~/.local/bin in their PATH. If the user is installing as root perhaps we should use a different PATH. I think we should also warn the user when installing as root.

[MahdiBM]

I think something simpler like this would be a better idea than #42.

I investigated what rustup does, and what I found is:

• First you curl | sh the rustup installer.
• The installer downloads another installer considering your platform.
• That other installer has some code to find proper rc files.
• They then set up the rc files to run their env script on every login (. "$HOME/.cargo/env").

The problem is setting up swiftly's installation script to do all these is a little bit weird/hard to me. Definitely doable though.

We might be able to do something like this:

• Get the current PATH (e.g. echo $PATH).
• See if it includes $HOME/local/bin. (If root, skip this?)
• If yes, then good. We can move on.
• If no, then try /usr/local/bin and then /usr/bin (checked both Linux/Macos).
• If still no, try any path ending in /bin that already contains any files/executables at all. (could skip this?)
• If no, ask user for a path. Possibly show them what they already have in PATH and ask them to choose (?), or tell them to provide any other path that works.

At some point we might need to ask for sudo if the user is not root or ask for entering a manual path.

[patrickfreed]

In general root users do not have ~/.local/bin in their PATH. If the user is installing as root perhaps we should use a different PATH.

I think always following the XDG base directory specification is still the right approach even for the root user, since installing something as root doesn't necessarily imply that you want that installation available to all users on a system. It is true that root doesn't have $HOME/.local/bin in their PATH by default, but #42 should make that situation not really a big deal anyways. Another important thing to consider is that the Swift toolchain bundles a bunch of executables with it that are more likely to clash if installed to a directory like /usr/local/bin, and the consequences of clashing in a system-wide directory like that are a bit more serious too.

I investigated what rustup does, and what I found is:

• First you curl | sh the rustup installer.
• The installer downloads another installer considering your platform.
• That other installer has some code to find proper rc files.
• They then set up the rc files to run their env script on every login (. "$HOME/.cargo/env").

The problem is setting up swiftly's installation script to do all these is a little bit weird/hard to me. Definitely doable though.

Yeah, this is something @adam-fowler suggested a while back. I've held off on doing it so far since I didn't want to accidentally clobber a user's shell configuration, but I think it's something we'll want to do eventually. I'll investigate it as part of #42 to see how much work is involved there. If it's not too bad, we can do it as part of that and otherwise split it off and address it in the future.

We might be able to do something like this:

This is an interesting idea, but I think it's best if we stick to a simpler approach that follows the base directory specification. It's a widely known and familiar spec that makes it so handing things like this is relatively straightforward and standardized. Rust notably doesn't follow the spec right now, but I don't think their example is necessarily one we want to follow in this case (rust-lang/cargo#1734 has 200 thumbs up). I also think that changing where the installation goes depending on the value of PATH might be surprising to some users.

So all that being said, I'm inclined to say that it's probably best that we don't do this, but that once we do #42, this issue will be less of a concern.

[patrickfreed]

Now that #42 has been completed, I think we can close this.