David Anthoff
David Anthoff
Not at the moment, my paragraph 3 above is essentially a suggestion to achieve that.
> The problem with environment variables is they are inherited by subprocesses. If I do `run(`/path/to/some/other/julia`)` from within the juliaup-launched process then the new `julia` subprocess will still have `JULIAUP_CURRENT_CHANNEL`...
Maybe long-term we should go with something completely crazy/different for IJulia: do away with version specific kernels entirely, just have one Julia kernel registered with IJulia. Instead of getting installed...
>> Hm, maybe? How would that be set, though? And also, that would only work for new Julia versions, it would be nice if we found a solution that also...
Argh, you are of course right! I'm just thinking mostly in the VS Code notebook API these days, where all of this is so much easier... So I think that...
I don't have strong views on the substance of this at all (hey, I'm a Windows guy, we don't have these problems!), but I am not keen to support two...
I have vague memories that https://github.com/JuliaLang/juliaup/blob/d3acca09e11e345e9b0fb856052ff80a99e40aa0/src/command_selfupdate.rs#L110 was added so that the dialog would somehow be placed on top of the terminal window, but don't remember the details. But might be...
`juliaup --version` or `juliaup -V` should do the trick. But we should definitely add an indication on what channel one is! I think `juliaup self channel` should just not error...
That looks like no binary was ever launched, right?
This looks maybe more like a Pkg.jl issue to me? CC @StefanKarpinski @KristofferC