JuliaLang
Disabling latest version message
Is there a way to disable the latest version message?
This can be particularly annoying since this does not respect options such as -q and prints to stdout, which anything relying on parsing the raw stdout from a julia script breaks as soon as such a update-message appears.
Btw. a workaround is to set the default version to a patch release, e.g. 1.9.3 or 1.9.3~aarch64. Some +X changes can still trigger it, but so far I only see +0 ;)
Hm, I'm confused, it looks to me as if the outdated version message is not printed to stdout, but stderr? See https://github.com/JuliaLang/juliaup/blob/main/src/bin/julialauncher.rs#L136.
Respecting -q would be hard because we would need to properly parse all Julia command line args to detect it. That would be generally useful, but is quite involved...
Respecting
-qwould be hard because we would need to properly parse all Julia command line args to detect it. That would be generally useful, but is quite involved...
Instead of a command-line flag, maybe an environment variable named JULIAUP_QUIET? And then if that environment variable is set to true or 1, you suppress these kinds of messages?
Instead of a command-line flag, maybe an environment variable named JULIAUP_QUIET? And then if that environment variable is set to true or 1, you suppress these kinds of messages?
I like this:)
I'd still like to first understand why the current implementation would break scripts that read the stdout stuff, because I think it is actually writing to stderr. Or was that just a false alarm?
I find a compromise. see juliaup status:
Default Channel Version Update
-------------------------------------------------------------------------
* release 1.9.4+0.x64.apple.darwin14 Update to 1.10.0+0.x64.apple.darwin14 available
If we install the current version (eg. 1.9.4) in specific Channel ("1.9.4") instead of "release", then julia won't output latest version message.
Alright, I think I'm going to close this issue. I believe the message is written to stderr, that seems fine. Please feel free to reopen if I'm missing something.
Alright, I think I'm going to close this issue. I believe the message is written to stderr, that seems fine. Please feel free to reopen if I'm missing something.
This was an issue for me when I used a quick one-off julia script to filter a vim buffer. It nicely cut down all the data to just what I was interested in, but it prepended the update message to the top. It didn't make sense to me to version the script since it's probably a throwaway, nor does it make sense to install specific julia versions on every machine where I might want to reuse a random script.
It would be nice to have a command-line option to suppress the update message that could be used in a shebang. I would suggest using the empty channel for this (ex. julia +) so it could be used as follows: #!/usr/bin/env -S julia + to pick the default channel with informational messages suppressed. Alternatively (or additionally), an environment variable would work too: #!/usr/bin/env -S JULIAUP_QUIET=1 julia
In my case it's not hard to delete the extra lines, so I don't think this is a priority, but it would add a bit of polish to the user experience. It might be worth leaving this issue open for that reason.
It would also be nice to disable this for nightly versions: I should already know by using nightly that a new version is available every day.
Could the message only be printed if you are about to enter the REPL / interactive mode? I don't want it printed for e.g. a CLI tool.
@KristofferC if we had the ability to distinguish when things will end in an interactive REPL we could do a lot of very useful things (in addition to your idea). For example, instead of just printing a message, we could actually prompt "Do you want to update? (y/n)" etc. The hold up is that my sense right now is that we would need to rewrite the Julia command line parser in Rust to be able to definitely tell whether we will be in interactive mode or not. I might be wrong about that, but I also had the impression that we would actually would need to know the semantics of different command line flags to determine that because I don't think one can just mechanically (without knowing which command line arg is which) tell at which point the ARGS for a script start. I might be wrong about that, in which case this whole thing would be easier...
Just an idea but if Julia had an option --banner-text={text} then juliaup could use it to inject the update notification only for the REPL. Julia already has the option --banner={yes|no|short|auto*} which controls the display of the startup banner for the REPL.
Instead of a command-line flag, maybe an environment variable named JULIAUP_QUIET? And then if that environment variable is set to true or 1, you suppress these kinds of messages?
Personally I would like both solutions: a command-line option and/or environment variable would be useful to suppress the update notification entirely. Seems reasonable to use -q to silence the notification as OP suggests since the documentation for -q in Julia makes it intuitive to assume that it could silence update notifications.
I'm encountering this right now using julia --quiet --history-file=no -e 'using Pkg; Pkg.activate("."); Pkg.instantiate()'
I'm new to julia but was quite surprised to find that --quiet does not suppress superfluous startup information. Is there no way to avoid this?
julia --quiet --history-file=no -e 'using Pkg; Pkg.activate("."); Pkg.instantiate()'
The latest version of Julia in the `1.11` channel is 1.11.3+0.aarch64.apple.darwin14. You currently have `1.11.2+0.aarch64.apple.darwin14` installed. Run:
juliaup update
in your terminal shell to install Julia 1.11.3+0.aarch64.apple.darwin14 and update the `1.11` channel to that version.
A easy way to disable the latest version message, just do not set your default version is release or lts, set it by
juliaup add <your current version>
juliaup default <your current version>
The banner? That's hidden with the -q flag. But that has nothing to do with juliaup.