1.8.1 not recognised as the latest version?

[ghyatzo]

Hello,

I am encountering this message everytime i start julia

The latest version of Julia in the `release~aarch64` channel is 1.7.2+0~aarch64. You currently have `1.8.1+0.aarch64` installed. Run:

  juliaup update

to install Julia 1.7.2+0~aarch64 and update the `release~aarch64` channel to that version.

I have installed the release, release~aarch64 and release~x64 versions, and a similar message pops up with all of them. Of course i ran juliaup update and I am at the latest version.

The installed julia versions run flawlessly though, so the functionality is not affected.

I am on an M1 mac with MacOS 12.5.1

[albheim]

What version of juliaup are you running, juliaup --version? Have you tried juliaup self update?

Don't really know what I'm talking about though, but my thought was that the self update is to update juliaup itself, and if you have an old juliaup maybe it has old definitions of the channels? Unclear how you managed to get the newer versions to begin with though.

[ghyatzo]

juliaup version is 1.7.23. juliaup self update return

Checking for self-updates
Juliaup unchanged on channel 'release' - 1.7.23

Not really sure what you mean by this though

Unclear how you managed to get the newer versions to begin with though.

[albheim]

Okay, no clue then.

Unclear how you managed to get the newer versions to begin with though.

was just in case

if you have an old juliaup maybe it has old definitions of the channels

was true, but since it seems it wasn't it can be disregarded.

[ghyatzo]

After checking the code, and try to guess where it was taking bad informations, I suspected that I had some issues with the installation folders. I tried to uninstall and reinstall and now it works.

by the way, the uninstalling process is waaay to aggressive. I know I had some misconfigured folders, but still, it deleted a lot of folders it wasn't supposed to. Without asking anything or doublechecking. It cost me an afternoon to reinstall everything the way it was. Please fix this. Also, maybe don't delete the config folder in $JULIA_DEPOT_PATH, it would be nice to keep the startup.jl file between reinstalls.

shall I close this issue and open another one with these comments?

[albheim]

I just tried the uninstall, and it seemed reasonable to me, the config was still there and so was any other julia related things I wouldn't expect juliaup to remove. How did you configure your julia?

Here is the code, on the surface it seems to only touch stuff it created, though I haven't gone deeper so I don't really know what is happening. https://github.com/JuliaLang/juliaup/blob/main/src/command_selfuninstall.rs

[ghyatzo]

I have a custom filesystem in ~/.local/ that mimicks the /usr/local/ structure, where I have a bin folder in the PATH where I symlink binaries from various packages. At the time I had juliaup and the rustup and rust toolchain installed in ~/.local/. At first I installed juliaup there, but julia still had the JULIA_DEPOT_PATH in ~/.julia.

Then, and this is where I think broke something, changed the depot path to ~/.local/julia, and updated julia through juliaup.

Upon uninstalling juliaup, my bin folder, as well as all the rustup and cargo folders got deleted. So my guess is that juliaup somehow recognised as its homefolder ~/.local instead of ~/.local/juliaup, or something along those lines.

Maybe the culprit is

if paths.juliauphome != paths.juliaupselfhome {
        eprint!("Deleting Juliaup folder {:?}.", paths.juliaupselfhome);
        match std::fs::remove_dir_all(&paths.juliaupselfhome) {
            Ok(_) => eprintln!(" Success."),
            Err(_) => eprintln!(" Failed.")
        };
    }

which in my case seems to resolve in remove_dir_all('~/.local')...

EDIT: Yup, just confirmed:

Why not just define a JULIAUP_HOME env variable, like rustup does? anyhow, calling remove_dir_all without checks on a folder you hope is the right one seems a bit reckless...

EDIT 2: this screenshot was taken with a fresh install.

[ghyatzo]

I found that the main issue is me symlinking the juliaup binary to ~/.local/bin/. Since at that point when generating the paths in global_paths.rs, my_own_path resolves to ~/.local/bin/juliaup therefore, juliaupselfbin = "~/.local/bin/" and juliaupselfhome = "~/.local/".

In a standard settings the values would be [...]/juliaup/bin/juliaup, [...]/juliaup/bin/, [...]/juliaup/.

May I propose a change on the notes of

let my_own_path = match std::env::var("JULIAUP_HOME") {
    Ok(val) => {
        let path = PathBuf::from(val.to_string().split(entry_sep).next().unwrap());
        if !path.is_absolute() { some error };
        path.join("bin").join("juliaup");
    }
    Err(_) => {
        std::end::current_exe()
            .with_context(|| "Could not determine the path of the running exe.")?;
    }
}

with JULIAUP_HOME pointing towards the juliaup folder that contains the binaries, and if not defined you fall back on the previous method of determining the juliaupselfhome. sorry, I am a bit rusty with rust (pun intended)

[ViralBShah]

I believe this is no longer an issue.

[ghyatzo]

I believe this is no longer an issue.

I can make a PR with what was proposed above, if that is what you mean. Or maybe my use case is too nonsense and not worth supporting? I do realise I set up things a bit unhortodoxly

[davidanthoff]

I'm tempted to just solve this in the following way: if a user selects an already existing folder as the install folder during the Juliaup folder, show a warning that one should not install Juliaup into an existing folder. Isn't that what we essentially want?

[davidanthoff]

Or we could also make the self uninstall command saver, i.e. instead of deleting the entire directory, only delete the (known) files that make up Juliaup, then check if the folders are empty and only then delete them. That actually seems by far the safest and easiest way around this.

[ghyatzo]

I'm tempted to just solve this in the following way: if a user selects an already existing folder as the install folder during the Juliaup folder, show a warning that one should not install Juliaup into an existing folder. Isn't that what we essentially want?

I believe the main issue is not that juliaup is within an existing folder but that the self_path is based on the running executable. The juliaup filesystem works even within other directories, the only problem is having a more solid way to reference the self_path, since if you symlink the executables then the self_path is no longer the original nested bin directory withing the juliaup home but the folder that you put the symlinks into.