IDEs for Julia
November 27, 2019 — February 8, 2023
IDE and workflow tips for Julia.
1 Workflow
all of this section is hopelessly outdated now.
The canonical sensible way to manage Julia projects is given by Bogumił Kamiński’s:
For every project keep a separate project environment…The steps to achieve it are easy:
- start
julia
in the folder in which you want to create a project- press
]
character to enter package manager mode- execute
generate [target folder name]
and press enter
You can activate such an environment with Pkg.activate(".")
or just use the Jupyter IDE, which does it automatically.
General tips: Look out for handy interactive introspection tricks, e.g. @which tells you which method your function invocation would invoke. There are other macros to tell you which file it comes from etc.
Use Revise.jl, and Project environments. If you don’t want to manually invoke Revise to detect code updates, you can use it automatically, which requires some version-dependent config in startup.jl
. (NB the VS Code version is different.) However, I do not do this since every project has startup overhead anyway, why not just put it in the config for a given project?
1.1 Literate coding
There is a package called Weave.jl which is inspired by R’s knitr
but compatible with Jupyter
, which is also not an IDE, but a good way of invoking reproducible self-documenting code. It could probably be used to fashion a working academic paper if you used the right pandoc hacks.
NB you can also use RMarkdown in Julia mode It’s not clear to me how graphing works in this setup.
See also Literate.jl for some similar functionality. Since notebook system Pluto stores notebooks as plain Julia files it might be worth your time to consider it as a literate coding system also.
2 IDEs/workbooks/editors
The most popular option seemed to be the default IDE, Juno, built on Atom. I believe it is deprecated in favour of Julia for VS Code. I sometimes use its Julia features but often just edit code and execute it via the REPL or IJulia
without any special integration. There is a degree of Jupyter integration through IJulia. Each of these methods has its own joys and frustrations.
Important: shortcuts to input Unicode in Julia seem to work across … everything?
2.1 Pluto
A pure Julia do-over of Jupyter with a similar look-and-feel but putatively simpler internals is Pluto (source).
A Pluto notebook is made up of small blocks of Julia code (cells) and together they form a reactive notebook. When you change a variable, Pluto automatically re-runs the cells that refer to it. Cells can even be placed in arbitrary order - intelligent syntax analysis figures out the dependencies between them and takes care of execution.
Cells can contain arbitrary Julia code, and you can use external libraries. >There are no code rewrites or wrappers, Pluto just looks at your code once before evaluation.
Your notebooks are saved as pure Julia files (sample), which you can then import as if you had been programming in a regular editor all along. You can also export your notebook with cell outputs as attractive HTML and PDF documents. By reordering cells and hiding code, you have full control over how you tell your story.
2.2 VS Code
VS Code is my preferred editor for everything. It has a good Julia extension. Because of Julia’s extended Unicode support it is recommended to have a good Unicode extension. Insert Unicode and Unicode Latex do the job. IMO this is much smoother; partly because VS Code is smoother than Atom, and partly because having my code in an external app is actually what I want most of the time. If you do want your code running in your IDE, VS Code recently acquired an integrated debugger, and the ability to execute code in situ in modules which means you can update arbitrary parts of the source manually.
2.3 Jupyter
You can use Jupyter with Julia via IJulia. This isn’t an IDE per se, it’s a sort-of-light interactive notebook. I wouldn’t want to edit code in Julia; for that I use a code editor. There are loads of those. However, for presenting experiments and prototyping, this is a nice environment. These two components have a zippier and stabler workflow for my style, by not trying to do everything at once badly (which is what Juno seems to be all about.)
IJulia is also not flawless. For a start it uses Jupyter, which I don’t love.
It does not have debugger integration, so you cannot run Julia debuggers from it.
For another thing, it does overzealous installs per default, profligately installing another copy of Jupyter, which you then have to maintain separately to the one you probably already had. Boring.
Here is how you fix that last problem:
tl;dr: For fish
conda create -n conda_jl python nomkl
conda activate conda_jl
env CONDA_JL_HOME="$HOME/miniconda3/envs/conda_jl" \
CONDA_JL_VERSION=3 \
PYTHON=(which python) \
JUPYTER=(which jupyter) \
julia
# Now, in Julia, run…
using Pkg
Pkg.add("IJulia")
Pkg.resolve()
Pkg.build()
For bash
conda create -n conda_jl python nomkl
conda activate conda_jl
CONDA_JL_HOME="$HOME/miniconda3/envs/conda_jl" \
CONDA_JL_VERSION=3 \
PYTHON=`which python` \
JUPYTER=`which jupyter` \
julia
using Pkg
Pkg.add("IJulia")
Pkg.resolve()
Pkg.build()
Taking that apart:
PyCall.jl invokes Python. Per default it installs yet another Conda Python, via Conda.jl, and defaults to the elderly Python 2.7. This is irritating for various reasons, such as being ancient, and eating your disk space with yet more versions of the same stuff that you already have installed in even more decrepit a state.
Here is how to use an existing version:
Here is how you use Conda, but with Python 3:
Here is how you use an existing environment
conda create -n conda_jl python
export CONDA_JL_HOME=~/miniconda3/envs/conda_jl
julia -e 'Pkg.build("Conda")'
Either way you should regularly run conda clean to stop your disk filling up with obsolete versions of obscure dependencies for that package you tried out that one time. As per standard practice.
You can bypass this by commanding it to use the perfectly good other Jupyter:
Now Julia appears as a normal kernel in your Jupyter setup. (This is only exciting for habitual Jupyter users and other anal retentives.)
If you want particular Jupyter kernels for particular Julia environments, it is possible: by using the following kernel interpreter template:
On Ubuntu a quirk of the build system sometimes requires
to avoid it demanding root permissions.
2.4 IntelliJ
Apparently the IntelliJ Julia plugin is undergoing development. Keep an eye on it for me and let me know?
2.5 Juno
Juno was the default. It had magical features — integrated debugger etc. It has an integrated installer experience that makes it quick to dive right in. It is transparent and easy. Juno is being phased out in favour of VS Code.
I do not like it. Juno is single-window only so you can’t use multiple monitors, and thus you end up squinting at tiny windows of code hidden between all the outputs. Atom’s panes aren’t well-designed for this use-case. I find there are a million tiny frictions distracting me from writing code in Juno. This is not to diss the excellent work that the creators of Juno have done. It is a good product; I’m just not in the aesthetic target market.
If you install Juno as an app, but you also already use Jupyter, which you have already installed, there is an additional annoyance in that it hijacks your Atom install in a confusing way and mangles your various package preferences. If you love Juno and Atom, I recommend installing Juno from within Atom via the uber-juno
package.