I recently updated my mac to latest Mojave (10.14.3) and it looks like IJulia no longer works (Safari 12.0.3). The executed cell just hangs and never returns. I see lots of JS errors.
Julia Version 1.1.0
Commit 80516ca202 (2019-01-21 21:24 UTC)
OS: macOS (x86_64-apple-darwin14.5.0)
CPU: Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
LLVM: libLLVM-6.0.1 (ORCJIT, skylake)
using Conda; Conda.update())
Thanks. I did a fresh install so it’s the latest Conda. Also, I can’t run
using Conda as it’s not explicitly added to the project.
(data-exploration) pkg> st
[a93c6f00] DataFrames v0.17.1
[c91e804a] Gadfly v1.0.1
[7073ff75] IJulia v1.17.0
[39abe10b] MySQL v0.7.0+ #master (https://github.com/JuliaDatabases/MySQL.jl.git)
[295af30f] Revise v1.0.2
[340e8cb6] SearchLight v0.8.0 [`~/.julia/dev/SearchLight`]
julia> using Conda
ERROR: ArgumentError: Package Conda not found in current path:
- Run `import Pkg; Pkg.add("Conda")` to install the Conda package.
Upon further investigation, the JS errors seem irrelevant. The real issue seems to be that the Julia Kernel doesn’t start. The Python kernel starts just fine (despite showing a bunch of JS errors too).
Hmmm… Looks like the actual problem is that IJulia won’t work unless it’s installed in the global environment, ie
(v1.1). If it is installed in a Project only, it seems to fail to start the kernel.
If you want to run it in particular project, you can do so but you need to install a custom kernel specification that passes
--project=.... when it launches
Is it possible to detect that IJulia is installed in a non-default project in the build script? It would be nice to not install the kernelspec and show a warning message when there is no IJulia in the default project.
I guess the build script could install the kernel for the current project?
You mean to create
~/.local/share/jupyter/kernels/julia-$PROJECT_ID-1.1 (and alike in non-*nix)? But how do you determine
$PROJECT_ID? Maybe the sha1 of the path to
Project.toml or something?
Actually, I think it’s better to discourage people for installing IJulia to non-default project. We have stackable
LOAD_PATH so I don’t think you need to install IJulia in each project for most of the cases (though I’m not super sure).
Thanks @essenciary! I have just been bit by the exact same problem you described here.
My Julia 1.6.2 kernel kept failing to load on my new Jupyter installation as well. I was unable to figure out the cause until I read this thread.
Typical setup (AFAIK)
To get Jupyter running, I did what I assume most people would given
README.md file. I let “IJulia create and manage its own Python/Jupyter installation” (quote from IJulia.jl/README.md at master · JuliaLang/IJulia.jl · GitHub):
What was atypical in my setup
I’m getting more proficient with environments now, so I never added
IJulia to the
v1.6 (default) environment for Julia v1.6.1.
- Instead, I created a project/environment called “
EnvJupyter” that I use for the sole purpose of launching Jupyter notebooks from a “clean” environment.
- The intent was to limit
EnvJupyter to only have essential (known) packages when the Jupyter notebook server is launched.
- So I added only
Revise to this
- I was really surprised to see that my Julia kernel kept failing to load in this clean environment.
Suggestions regarding custom kernel specs
- Sadly, I don’t fully appreciate the suggestions given above by @stevengj & @tkf regarding custom kernel specifications (I would need to play around with this feature to get a better feel).
But, from what I can tell:
- It looks like they are customizations allowing users to overwrite the default behaviour, which is to initialize kernels with the default
v1.6 environment (or whatever version of Julia you are using).
What I would expect
Maybe this is just me, but I would have expected there to be a little blurb on the
IJulia/README.md file explaining that,
- Kernels are initialized from Julia’s default (ex:
v1.6) release-dependent environment, and that
IJulia had to be added to that environment for Kernels to be initialized.
At the moment, the README.md file does point to the steps for specifying custom kernels, but does not really explain how it relates to the default behaviour. My guess is that users are expected to piece together this concept from the “custom kernel” section and the installation section of the docs.
Then again, I suppose this might all just be my tendency to “do things the wrong way”.