Use jlenv to pick a Julia version for your application and guarantee that your development environment matches production.
Powerful in development. Specify your app’s Julia version once, in a single file. Keep all your teammates on the same page. No headaches running apps on different versions of Julia. Just Works™ from the command line and with app servers like Pow. Override the Julia version anytime: just set an environment variable.
Rock-solid in production. Your application’s executables are its interface with ops. The Julia version dependency lives in one place—your app—so upgrades and rollbacks are atomic, even when you switch versions.
One thing well. jlenv is concerned solely with switching Julia versions. It’s simple and predictable. A rich plugin ecosystem lets you tailor it to suit your needs. Compile your own Julia versions, or use the julia-build plugin to automate the process. See more plugins.
- Why jlenv?
- How It Works
- Command Reference
- jlenv plugins
- Authoring plugins
- How to enable jlenv everywhere
- Deploying with jlenv
- Understanding binstubs
- Unix shell initialization
- Environment variables
Install jlenv. Note that this also installs
julia-build, so you’ll be ready to install other Julia versions out of the box.
jlenv initand follow the instructions to set up jlenv integration with your shell. This is the step that will make running
julia“see” the Julia version that you choose with jlenv.
Close your Terminal window and open a new one so your changes take effect.
That’s it! Installing jlenv includes julia-build, so now you’re ready to install some other Julia versions using
This will get you going with the latest version of jlenv without needing a systemwide install.
Clone jlenv into
git clone https://github.com/jlenv/jlenv.git ~/.jlenv
Optionally, try to compile dynamic bash extension to speed up jlenv. Don’t worry if it fails; jlenv will still work normally:
cd ~/.jlenv src/configure make -C src
$PATHfor access to the
echo 'export PATH="$HOME/.jlenv/bin:$PATH"' >> ~/.bash_profile
Ubuntu Desktop note: Modify your
Zsh note: Modify your
~/.zshrcfile instead of
~/.jlenv/bin/jlenv initand follow the instructions to set up jlenv integration with your shell. This is the step that will make running
julia“see” the Julia version that you choose with jlenv.
Restart your shell so that PATH changes take effect. (Opening a new terminal tab will usually do it.)
If you’ve installed jlenv manually using Git, you can upgrade to the latest version by pulling from GitHub:
cd ~/.jlenv git pull
Skip this section unless you must know what every line in your shell profile is doing.
jlenv init is the only command that crosses the line of loading extra commands into your shell. Coming from RVM, some of you might be opposed to this idea. Here’s what
jlenv init actually does:
Sets up your shims path. This is the only requirement for jlenv to function properly. You can do this by hand by prepending
Installs autocompletion. This is entirely optional but pretty useful. Sourcing
~/.jlenv/completions/jlenv.bashwill set that up. There is also a
~/.jlenv/completions/jlenv.zshfor Zsh users.
Rehashes shims. From time to time you’ll need to rebuild your shim files. Doing this automatically makes sure everything is up to date. You can always run
Installs the sh dispatcher. This bit is also optional, but allows jlenv and plugins to change variables in your current shell, making commands like
jlenv shellpossible. The sh dispatcher doesn’t do anything crazy like override
cdor hack your shell prompt, but if for some reason you need
jlenvto be a real script rather than a shell function, you can safely skip it.
jlenv init - for yourself to see exactly what happens under the hood.
jlenv install command doesn’t ship with jlenv out of the box, but is provided by the julia-build project. If you installed it either as part of GitHub checkout process outlined above, you should be able to:
# list all available versions: jlenv install -l # install a Julia version: jlenv install v1.0.3
Alternatively to the
install command, you can download and compile Julia manually as a subdirectory of
~/.jlenv/versions/. An entry in that directory can also be a symlink to a Julia version installed elsewhere on the filesystem. jlenv doesn’t care; it will simply treat any entry in the
versions/ directory as a separate Julia version.
As time goes on, Julia versions you install will accumulate in your
To remove old Julia versions, simply
rm -rf the directory of the version you want to remove. You can find the directory of a particular Julia version with the
jlenv prefix command, e.g.
jlenv prefix 1.0.0.
The julia-build plugin provides an
jlenv uninstall command to automate the removal process.
The simplicity of jlenv makes it easy to temporarily disable it, or uninstall from the system.
- To disable jlenv managing your Julia versions, simply remove the
jlenv initline from your shell startup configuration. This will remove jlenv shims directory from PATH, and future invocations like
juliawill execute the system Julia version, as before jlenv.
jlenv will still be accessible on the command line, but your Julia apps won’t be affected by version switching.
- To completely uninstall jlenv, perform step (1) and then remove its root directory. This will delete all Julia versions that were installed under
rm -rf `jlenv root`
You can affect how jlenv operates with the following settings:
| ||Specifies the Julia version to be used. Also see |
| || ||Defines the directory under which Julia versions and shims reside. |
| ||Outputs debug information. |
| ||[See Authoring Plugins][/authoring-plugins#jlenv-hooks]||Colon-separated list of paths searched for jlenv hooks.|
| || ||Directory to start searching for |
The jlenv source code is hosted on GitHub. It’s clean, modular, and easy to understand, even if you’re not a shell hacker.
Tests are executed using Bats:
bats test bats test/<file>.bats
Please feel free to submit pull requests and file bugs on the issue tracker.