The enhanced Python fork of JILL -- Julia Installer for Linux (and every other platform) -- Light
For the first time users of jill, you will need to install it using pip: pip install jill --user -U. Also use this to upgrade JILL version.
Python >= 3.6 is required. For base docker images, you also need to make sure wget and gnupg
are installed.
When you type jill install, it does the following things:
julia, julia-1, julia-1.6For common Julia users:
jill installjill install 1jill install 1.6jill install 1.6.2, jill install 1.7.0-beta3jill install --unstableNote that for Julia 1.10, you'll have to install it with jill install '"1.10"' because of the
python-fire limit.
For Julia developers and maintainers:
jill install latest. This gives you julia-latest.jill install 1.8.0+cc4be25c (<major>.<minor>.<patch>+<build> with at least the first 7 characters of the
hash). This gives you julia-dev.Some flags that can be useful:
jill install --confirmjill install --upstream Officialjill install --keep_downloadsjill install --reinstallTo start Julia, you can use predefined JILL symlinks such as julia. jill install uses the following rule makes sure
that you're always using the latest stable release.
Stable releases:
julia points to the latest Julia release.julia-1 points to the latest 1.y.z Julia release.julia-1.6 points to the latest 1.6.z Julia release.For unstable releases such as 1.7.0-beta3, installing it via jill install 1.7 --unstable or
jill install 1.7.0-beta3 will only give you julia-1.7; it won't make symlinks for julia or
julia-1.
To dance on edge:
julia-latest points to the nightly build from jill install latestjulia-dev points to the julia CI build artifacts from, for example, jill install 1.8.0+cc4be25c.jill list [version] gives you every symlinks and their target Julia versions.
For non-windows system, you are free to use ln command to change the symlink targets. For Windows
it uses an entry .cmd file for this so you'll need to copy them. In the meantime, jill switch
provides a simple and unified way to do this:
jill switch 1.6: let julia points to the latest julia 1.6.z release.jill switch <path/to/my/own/julia/executable>: let julia points to custom executables.jill switch 1.6 --target julia-1: let julia-1 points to the latest julia 1.6.z release.By default, JILL tries to be smart and will download contents from the nearest upstream. You can
get the information of all upstreams via jill upstream. Here's what I get in my laptop, I live in
China so the official upstreams aren't so accessible for me :(
To temporarily disable this feature, you can use flag --upstream <server_name>. For instance,
jill install --upstream Official will faithfully download from the official julialang s3 bucket.
To permanently disable this feature, you can set environment variable JILL_UPSTREAM.
Note that flag is of higher priority than environment variable. For example, if JILL_UPSTREAM is
set to mirror server "TUNA", you can still download from the official source via jill install --upstream Official.
Here's the default JILL installation and symlink directories:
| system | installation directory | symlink directory |
|---|---|---|
| macOS | /Applications | ~/.local/bin |
| Linux/FreeBSD | ~/packages/julias | ~/.local/bin |
| Windows | ~\AppData\Local\julias | ~\AppData\Local\julias\bin |
For example, on Linux jill install 1.6.2 will have a julia folder in ~/packages/julias/julia-1.6
and symlinks julia/julia-1/julia-1.6 created in ~/.local/bin.
Particularly, if you're using jill as root user, you will do a system-wide installation:
/opt/julias for Linux/FreeBSD./usr/local/bin for Linux/FreeBSD/macOS.To change the default JILL installation and symlink directories, you can set environment variables
JILL_INSTALL_DIR and JILL_SYMLINK_DIR.
(Deprecated) jill install also provides two flag --install_dir <dirpath> and --symlink_dir <dirpath>, they have higher priority than the environment variables JILL_INSTALL_DIR and
JILL_SYMLINK_DIR.
jill is made as a convenient tool and it can sometimes be annoying passing flags to it. There are
some predefined environment variables that you can use to set the default values:
JILL_UPSTREAM: --upstreamJILL_SYMLINK_DIR: --symlink_dirJILL_INSTALL_DIR: --install_dirThe flag version has higher priority than the environment variable version.
If you're tired of seeing (xx days old master) in your nightly build version, then jill can
make your nightly build always the latest version using cron:
# /etc/cron.d/jill
PATH=/usr/local/bin:/usr/sbin:/usr/sbin:/usr/bin:/sbin:/bin
# install a fresh nightly build every day
* 0 * * * root jill install latest --confirm --upstream Official
If it's an public mirror and you want to share it worldwide to other users of JILL. You can add an entry to the public registry, make a PR, then I will tag a new release for that.
Please check the sources.json format for more detailed information on the
format.
To add new private upstream, you can create a file ~/.config/jill/sources.json (fow Windows it is
~/AppData/Local/julias/sources.json) and add your own upstream configuration just like the JILL
sources.json does. Once this is done JILL will recognize this new
upstream entry.
Please check the sources.json format for more detailed information on the
format.
There are two ways to do so:
aws s3 sync, this should be the easiest way to do so I highly recommend this.jill mirror command with mirror config example. I
didn't know about the aws s3 sync stuff when I implemented this.The Julia release mirror does not contain Julia package contents, to mirror all the Julia packages and artifacts (which requires >1.5Tb storage), you can use StorageMirrorServer.jl.
jill.py also provides a set of Python API:
from jill.install import install_julia
from jill.download import download_package
# equivalent to `jill install --confirm`
install_julia(confirm=True)
# equivalent to `jill download`
download_package()
You can read its docstring (e.g., ?install_julia) for more information.
Distro package managers (e.g., apt, pac) is likely to provide a broken Julia with incorrect
binary dependencies (e.g., LLVM ) versions. Hence it's recommended to download and extract the
Julia binary provided in Julia Downloads. jill.py doesn't do
anything magical, but just makes such operation even stupid.
At first I found myself needing a simple tool to download and install Julia on my macbook and
servers in our lab, I made my own shell scripts and I'd like to share it with others. Then I found
the jill.sh project, Abel knows a lot shell so I decide to contribute my macOS Julia
installer to jill.sh.
There are three main reasons for why I decided to start my Python fork:
For some "obvious" reason, Julia People don't like Python and I understand it. (I also don't like Python after being advanced Julia user for more than 3 years) But to be honest, revisiting this project, I find using Python is one of the best-made decision during the entire project. Here is the reason: no matter how you enjoy Julia (or C++, Rust), Python is one of the best successful programming language for sever maintenance purpose. Users can easily found tons of "how-to" solutions about Python and it's easy to write, deploy, and ship Python codes to the world via PyPI.
And again, I live in China so I want to rely on services that are easily accessible in China, PyPI
is, GitHub and AWS S3 bucket aren't. A recent Julia installer project juliaup written in Rust
solves the Python dependency problem very well, but the tradeoff is that juliaup needs its own
distributing system (currently GitHub and S3 bucket) to make sure it can be reliably downloaded to
user machine. And for this it just won't be as good as PyPI in the foreseeable future.
jill.py?Yes, jill.py use GPG to check every tarballs after downloading. Also, *.dmg/*.pkg for macOS
and .exe for Windows are already signed.
jill.sh and jill.pyjill.sh is a shell script that works quite well on Linux x86/x64 machines. jill.py is
an enhanced python package that focus on Julia installation and version management, and brings a
unified user experience on all platforms.
julia fails to startThe symlink julia are stored in JILL predefined symlinks
dir thus you have to make sure this folder is in
PATH. Search "how to add folder to PATH on xxx system" you will get a lot of solutions.
1.6.1 and 1.6.2)Generally, you should not care about patch version differences so jill.py make it explicitly that
only one of 1.6.x can exist. If you insist to have multiple patch versions, you could use jill install --install_dir <some_other_folder> to install Julia in other folder, and then manually make
a symlink back. As I just said, in most cases, common users should not care about this patch version
difference and should just use the latest patch release.
Use jill download [version] [--sys <system>] [--arch <arch>]. Check jill download --help for
more details.
For Julia (>= 1.5.0) in Linux with musl libc, you can just do jill install and it gives you the
right Julia binary. To download the musl libc binary using jill download, you will need to pass
--sys musl flag.
Yes it's supported. Because macOS ARM version is still of tier-3 support, jill.py will by default
install the x86_64 version. If you want to use the ARM version, you can install it via jill install --preferred-arch arm64.
If you're confident, try jill install --bypass-ssl.
If for some reason you prefer to download julia without generating symbolic links jill install --skip-symlinks
FAQs
JILL -- Julia Installer for Linux (MacOS, Windows and FreeBSD) -- Light
We found that jill demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.
Security News
The Ultralytics' PyPI Package was compromised four times in one weekend through GitHub Actions cache poisoning and failure to rotate previously compromised API tokens.
Security News
Research
Socket researchers found a malicious Maven package impersonating the legitimate ‘XZ for Java’ library, introducing a backdoor for remote code execution.