Update to Julia 1.8 and set up kernel

[facusapienza21]

Recently, Julia has released version 1.8. Currently we are using Julia 1.7. Would it be possible to install Julia 1.8 in the JupyterHub and also keep Julia 1.7?

This will also help us when working with Jupyter Notebooks. Usually @JordiBolibar and I run Julia in VSCode, but recently I observed that the ikernel for Julia doesn't work. Then it will be ideal to have Julia 1.8 installed alongside with the iPython kernel for running in a notebook.

Thank you very much!!!

[JordiBolibar]

Julia 1.8.1 was released yesterday, so it would be awesome to target that latest release 😄

[consideRatio]

Recently, Julia has released version 1.8. Currently we are using Julia 1.7. Would it be possible to install Julia 1.8 in the JupyterHub and also keep Julia 1.7?

While I could add juliaup that I found by googling, it would significantly raise the complexity and maintainability challenge of this image. I'm quite strongly opined towards not having multiple versions of julia provided in the image, and suggest that we stay with the version that works and are a bit slow to adopt the latest features unless needed.

@facusapienza21 did you want to workaround a problem by having multiple versions of julia (recently I observed that the ikernel for Julia doesn't work)? If so, I'll work to resolve that thoroughly somehow as adding another version of julia is something I think will come back and bite us with even more complexity in the long run.

[consideRatio]

I'm not sure if this is relevant, but note that I can access Julia as a kernel. If you can't it could relate to overriding default configurations about where kernels are found etc in a jupyter related configuration file for example.

[consideRatio]

Julia 1.8.1 installed, and the kernel is detected for me still

[facusapienza21]

Thank you @consideRatio !

I agree that having two different versions of Julia could be not the best idea. If that is the case, I would double-check with @JordiBolibar that moving to Julia 1.8 is the best idea. I personally think it's better to move now to Julia 1.8 since the community is moving super fast and I would like to work with the last version of Julia.

Regarding the problem with the kernel: I also see the notebook option with Julia and now I can see both Julia 1.7 and 1.8 as options in the launcher. The problem I am having is that when I open the notebook with the Julia kernel it doesn't work: running any line of code results in waiting [*] and then the kernel crashes (or more specifically, I see the No Kernel message in the kernel option window).

[consideRatio]

The problem I am having is that when I open the notebook with the Julia kernel it doesn't work: running any line of code results in waiting [*] and then the kernel crashes (or more specifically, I see the No Kernel message in the kernel option window).

I accessed your running server and could reproduce what you described. Note that I could reproduce it without running code, just by looking at the top right corner I see a kernel status indicator that said "Kernel connecting" and then "No kernel" after a while of thinking.

I visited a terminal and run jupyter kernelspec list and then I got an error like...

bash: /home/jovyan/.local/bin/jupyter: /srv/conda/bin/python3.9: bad interpreter: No such file or directory

I conclude that you have a jupyter executable in .local/bin which is a bit unexpected, and it is failing for some reason that I didn't felt relevant to dig into - it probably shouldn't be a jupyter executable there to be used at all. It is what is used by default, and maybe that is causing issues?

My suggestion is to cleanup your .local folder, starting with cleaning up executable files in .local/bin.

For reference, if I run the kernelspec list command on your server it sais...

$ /srv/conda/envs/notebook/bin/jupyter kernelspec list

Available kernels:
  finse_massbalance          /home/jovyan/.local/share/jupyter/kernels/finse_massbalance
  julia-1.7                  /home/jovyan/.local/share/jupyter/kernels/julia-1.7
  mars_mag_pymc3             /home/jovyan/.local/share/jupyter/kernels/mars_mag_pymc3
  marsmag_environment.yml    /home/jovyan/.local/share/jupyter/kernels/marsmag_environment.yml
  myenv                      /home/jovyan/.local/share/jupyter/kernels/myenv
  python3                    /home/jovyan/.local/share/jupyter/kernels/python3
  julia-1.8                  /srv/conda/envs/notebook/share/jupyter/kernels/julia-1.8

If I run it on my server, it sais:

$ /srv/conda/envs/notebook/bin/jupyter kernelspec list

Available kernels:
  julia-1.8    /srv/conda/envs/notebook/share/jupyter/kernels/julia-1.8
  python3      /srv/conda/envs/notebook/share/jupyter/kernels/python3

[facusapienza21]

Thank you @consideRatio for the suggestion!

I already removed all the other files from my machine but I am still having the same issue. Now, when I enter /srv/conda/envs/notebook/bin/jupyter kernelspec list I see the same message than you, but the Julia kernel is not working. Any idea of what may be failing? Thank you!

[consideRatio]

It must be something coupled with your setup. I would presume configuration local to you, or previous state of julia etc.

I'd look for a .julia folder or .cache or .local or .juliarc etc and think if that could influence you.

I'll debug it on your server and see what i find out.

[consideRatio]

Hmmm the server is running already, and you have two servers using the same home folder started atm.

I failed to recover things to a functioning state and didn't dare intervene further at the risk of corrupting something of what you do atm. This is what I'd do to recover.

1. Close down all your servers via https://hub.jupytearth.org/hub/home
2. Start your default server via https://hub.jupytearth.org/hub/home
3. Open a terminal and: mv .local .local-backup-2022-09-22
4. Restart your server and attempt to start julia
5. If it doesn't work, ping me again and I'll inspect the logs to obsreve what failed at that time when you were in a quite clean state.

The current failures have been...

[I 2022-09-22 09:18:26.679 SingleUserNotebookApp restarter:120] KernelRestarter: restarting kernel (4/5), new random ports
ERROR: LoadError: ArgumentError: Package IJulia not found in current path.
- Run `import Pkg; Pkg.add("IJulia")` to install the IJulia package.
Stacktrace:
 [1] macro expansion
   @ ./loading.jl:1163 [inlined]
 [2] macro expansion
   @ ./lock.jl:223 [inlined]
 [3] require(into::Module, mod::Symbol)
   @ Base ./loading.jl:1144
in expression starting at /srv/julia/pkg/packages/IJulia/AQu2H/src/kernel.jl:1
[W 2022-09-22 09:18:29.692 SingleUserNotebookApp restarter:113] KernelRestarter: restart failed
[W 2022-09-22 09:18:29.693 SingleUserNotebookApp kernelmanager:146] Kernel ef2c1b83-1b1c-4993-8e08-7bd17c78af59 died, removing from map.

I conclude this to relate to you have a Python environment by default that isn't the base environment in some way. I'm not sure, but when I wrote /srv/conda/envs/notebook/bin/jupyter kernelspec list I saw that you had a python kernel registered directly from your home folder and not the base environment. I think that causes this problem.

I think if you have a python environment that becomes the default python environment of choice over the base environment in the docker image - I imagine we observe this breaking.

[facusapienza21]

I just followed the steps but it's still not working. I am running everything in a small machine called Julia_test, if you need to jump in to that one and see what is going on, go ahead. I guess this may be related to a problem I induced in my configuration while trying to install iPython kernels by my own.

As a side comment, since the last change from Julia 1.7 to Julia 1.8 I always observe this message once I lunch a new server:

Even if I entered build the message reapears the next time I open a terminal. Do you think this could be related to the problem I have?

[consideRatio]

I also get the ipyspin stuff, ignore it as unrelated. I can investigate that separately, I'm quite confident its not related.

I'll look into the state of the server etc and try get it running. I'll restart the server etc doing this.

[consideRatio]

@facusapienza21 I need to work on this alone to figure this out. Atm I see three separate servers in some state active. I hope to just work with a single server accessed by a single browser. Specifically, the one without a name because that also adds some complexity that is worth not tanglging with at the same time.

jupyter-facusapienza21---4aulia-5ftest 1/1 Running 0 7s jupyter-jordibolibar---4f-44-49-4e-4e 0/1 Pending 0 15m jupyter-jordibolibar---4f-44-49-4e-4e-2d2 0/1 PodInitializing 0 9m55s

Ping me if you hare hands off and I'll try get this working!

[consideRatio]

Oooh mistook jordi's servers for your servers. Okay only one server running there after all, sorry for the noise! But I'd still like to ensure I'm the sole user of the server as this wasn't quickly fixed to minimize complexity.

[facusapienza21]

Yeah! I am leaving Julia_test open for tracking this issue, but I am not actually working there. Feel free to jump in there if you need. Thank you for taking care of this! Really appreciated :)

[consideRatio]

@facusapienza21 but sadly they are coupled, they all use the same storage, and the common storage in your home folder is what I'm concerned causes the problem.

I can work on this right now. Can I take full control of everything for 10 minutes or so? If you shut down all servers and close all browser tabs and ping me back, I'll start working those 10 minutes to get this resolved.

[facusapienza21]

I just closed all my servers! Go for it! Thank you!

[consideRatio]

Thanks! I'm on it!

[facusapienza21]

Excellent! Just a small comment: I am with Jordi and he has the same problem now when trying to execute a Jupyter notebook with the Julia 1.8 kernel. I think this was working for him before.

[consideRatio]

=/ Okay, then its not just you... Trying to see if I reproduce this on my server when after having cleaned away everything in my server that could influence the default.

[consideRatio]

@facusapienza21 @JordiBolibar okay!

My process of debugging this was to inspect the home folder with ls -alh and consider if any file would have configuration that influenced julia, then rename file/folder like mv <name> <name>-backup-2022-09-22. After each attemt, I restarted the server and opened a new untitled julia kernel notebook to see if it connected to the kernel successfully.

After doing this 10 or so times, I identified that .bash_profile was to blame for @facusapienza21, and I've guessed it may be to blame for @JordiBolibar as well where it is inpacting a JULIA_DEPOT_PATH environment variable.

I've renamed and let those stay renamed as .bash_profile-backup-2022-09-22 for both of you, @JordiBolibar if you restart your server, it may work for you as well now. It works for @facusapienza21 now at least!

[facusapienza21]

Hi @consideRatio ! Thank you for fixing this.

Wwith @JordiBolibar we intentionally changed the .bash_profile so that we can use the same compiled versions of the Julia packages we use every time we open a new session (that is, we wanted the pre-compiled versions to be persistent). Without that change, every time we opened a new server we needed to precompile the libraries, which takes several minutes. You can see the solution we found with @fperez some time ago in #118 , where the solution for this problem was exactly changing the JULIA_DEPOT_FILE. I think it will be worth exploring how can we simultaneously have the Julia kernel and the persisted directory for precompiled julia packages at the same time.

[consideRatio]

Okay I figure the concrete path forward is to:

1. understand the environment variables we have at our disposal documented here
2. figure out what we desire practically
3. test if we can accomplish that by setting the environment variables, either by the user or by default in our image

I think perhaps what is wanted is that packages installed are installed in the home folder by default, but, that that julia is also aware of things installed outside the home folder. Practically, I guess this could be done by declaring a JULIA_LOAD_PATH and/or JULIA_DEPOT_PATH environment variable to be two separate locations.

Currently our image declare the following:

ENV JULIA_PATH /srv/julia
ENV JULIA_DEPOT_PATH ${JULIA_PATH}/pkg

Note that the name JULIA_PATH isn't actually recognized by julia, it was declared in the dockerimage for use by the docker image scripts only.

@facusapienza21 could you perhaps experiment with making this change in your .bash_profile? I think it may result in Julia looking for IJulia outside your home folder (/srv/julia/pkg) while also respecting things inside your home folder if you add things there.

+export JULIA_DEPOT_PATH="$HOME/.julia:$JULIA_DEPOT_PATH"
-export JULIA_DEPOT_PATH="$HOME/.julia:"

We can make this the default for the image if that works well. Note though that whenever the image changes version of julia, the home folder files needs to be whiped and updated I think - because I assume they are coupled to the julia binary version tightly.

NOTE: Server restarts may be required for the changes to impact you - not sure if you need to or not.