Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use the XDG standard bin directory on linux? #247

Closed
c42f opened this issue Feb 11, 2022 · 13 comments
Closed

Use the XDG standard bin directory on linux? #247

c42f opened this issue Feb 11, 2022 · 13 comments
Labels
enhancement New feature or request
Milestone

Comments

@c42f
Copy link
Member

c42f commented Feb 11, 2022

The $HOME/.local/bin directory is recommended by the XDG standard as a place to store executables:

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.

So perhaps juliaup for linux should be installed into $HOME/.local/bin/juliaup rather than a special juliaup directory? This should also help with #222 because it should do away with needing to modify .bashrc on linux. I'm generally not keen on tools messing with my shell configuration in an automated way!

See also https://unix.stackexchange.com/questions/316765/which-distributions-have-home-local-bin-in-path

This was similarly discussed by rustup people, but stalled for no apparent good reason: rust-lang/rustup#247

Originally posted by @c42f in #143 (comment)

@DilumAluthge
Copy link
Member

DilumAluthge commented Feb 11, 2022

I very strongly prefer that all Julia-related stuff (including anything that juliaup creates) goes under the ~/.julia directory by default.

I think it's fine to have an option that lets users opt-in to the XDG directories. But I don't want it to be the default behavior.

@DilumAluthge
Copy link
Member

Somewhat related: JuliaLang/julia#4630

@simeonschaub
Copy link
Member

Note that if the Juliaup binaries are installed system-wide and you turn on symlink creation for channels, those symlinks will actually be installed into ~/.local/bin by default.

@DilumAluthge
Copy link
Member

Note that if the Juliaup binaries are installed system-wide and you turn on symlink creation for channels, those symlinks will actually be installed into ~/.local/bin by default.

Is ~/.local/bin in the default PATH on Linux?

@simeonschaub
Copy link
Member

Not necessarily, but there will be a warning if not

@DilumAluthge
Copy link
Member

Then why not just make the symlinks in e.g. ~/.julia/juliaup/bin, and then add ~/.julia/juliaup/bin to the PATH? (At least by default, with an option for users to change it if they like.)

As I wrote above, I think it's really convenient for everything Julia related to always be located in $HOME/.julia by default, regardless of the operating system.

@c42f
Copy link
Member Author

c42f commented Feb 11, 2022

Yikes, JuliaLang/julia#4630 has some pretty strong opinions there.

To be honest, my main gripe with the current juliaup default installation location is that it's creating a special .juliaup directory just for juliaup. This seems far from ideal, and I'd be almost equally happy if we centralized to using the .julia directory for the binaries. We have all other downloaded stuff in there including artifacts, etc, after all.

Not needing to modify the user's .bashrc is still an enticing benefit of installing juliaup itself into the XDG directory, however.

Is ~/.local/bin in the default PATH on Linux?

It certainly is on Ubuntu 18.04, and apparently should generally be on systemd-based distributions. See man file-hierarchy and systemd-path. Some more info at https://unix.stackexchange.com/questions/316765/which-distributions-have-home-local-bin-in-path

@davidanthoff
Copy link
Collaborator

Yeah, I have to say the longer I've been thinking about it, I'm also not super happy about the ~/.juliaup directory. I think my original thinking had been that one could install one juliaup, and then switch between different depots by changing the julia depot env variable. The other thinking had been that when juliaup is not installed by the scripts, but rather a package manager, it also ends up somewhere outside of ~/.julia, and I thought maybe that would be nice. But I think overall I'm no longer really sold by any of this...

I think I'm kind of gravitating towards putting the binaries into ~/.julia/juliaup/bin when a user installs things via a script.

The second (somewhat orthogonal) question is about the PATH stuff. I really, really dislike that we are modifying shell scripts. It just feels incredibly hacky. So in my ideal world we would somehow detect whether there is a user profile specific folder that is already on the PATH (like ~/.local/bin), and if that is the case, put a symlink in there, and only if that is not the case start to edit startup files. But reliably detecting whether that is the case seemed even more complicated. Sooo, I don't really know what to do :)

We should probably also play a system wide install option mentally through, and see how that might change things.

@c42f
Copy link
Member Author

c42f commented Feb 12, 2022

So in my ideal world we would somehow detect whether there is a user profile specific folder that is already on the PATH (like ~/.local/bin)

I did some investigation on my local system and here's how it's set up:

  • The PATH is set up by default using /etc/skel/.profile which is copied to user's home directory during adduser
  • The /etc/skel/.profile on my system has
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

So unfortunately this is quite a mess because the user might have customized their .profile or .local/bin might not exist (and then wouldn't be in the path). I don't know whether other distros do better with this kind of thing.

@davidanthoff
Copy link
Collaborator

Yep, that is where I got stuck as well: all the startup scripts I ever saw seem to check whether the folder exists before they add it to the PATH... I guess one option could be to check whether .local/bin exists, if not, create it, spawn a new shell, check whether it is on the PATH then... Also pretty messy, but I think at the end of the day that is the reality of installers: messy, beginning to end... (except on Windows, I have to say, the design of MSIX is just like literally exactly how one would hope things should work).

@DilumAluthge
Copy link
Member

I think that ~/.julia/juliaup is a lot better than ~/.juliaup. If we can keep as much stuff under ~/.julia as possible, I think that would be best.

@davidanthoff
Copy link
Collaborator

#329 now defaults to installing juliaup itself into .julia/juliaup.

@davidanthoff davidanthoff added the enhancement New feature or request label Jul 17, 2022
@davidanthoff davidanthoff added this to the Backlog milestone Jul 17, 2022
@davidanthoff
Copy link
Collaborator

Just a quick update here: I reverted #329, so Juliaup by default installs itself into ~/.juliaup again. The why is explained at #447.

I think the best strategy on all of this is that medium term on Linux we try to get this entire Juliaup stuff into the system package managers as the julia package. I really want sudo apt install julia to just install Juliaup into whatever the best place is on a Debian based system and be done with it. I think we are getting closer to a place where this could all work.

I'm going to close this for now, as I think the current system seems to work well enough across many platforms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants