Ann: jlenv & plugins - Robust Julia version management
This is a 1.0.0 release of the Julia port of the rbnev/pyenv tools and plugins.
As well as some projects supporting Julia configuration and version management.
NOTE:
You can install different versions of julia using the julia-build script.
As you will see this script will be deprecated with the next major release of jlenv. It will be replaced with a tool that verifies GPG signatures and can run stand alone or as a jlenv plugin.
Where a tool has been forked, it has generally been from the ruby code base.
Each tool is under develpment, with the immediate aim being interoperability.
I have added (bats) preliminary tests for the plugins I selected.
The biggest area of âwet-paintâ is around the proper/best practice use of
Julia environment variable settings - runtime and build time.
Released
The components considered released are âpinnedâ on the jlenv organization GitHub page.
These projects have test suites that pass.
jlenv-cookbook:
The Chef Git Resource breaks when used in no-TTY environments, this breaks
dokken test environment. A workaround is in place and being tested.
Likely released before the next major version of jlenv.
julia-install:
A standalone script to install Julia versions. This port is underway.
and will be released when the test suite passes and jlenv is
compatible with the julia-install conventions/assumptions.
Likely released with the next major version of jlenv.
jlenv-install:
A plugin that adds julia-install functioanlity to jlenv. This needs jlenv and
julia-install to work off the same conventions/assumptions.
Likely released with the next major version of jlenv.
jlenv-installer:
This is a install convenience script.
Likely released with the next major version of jlenv.
chjulia:
A simpler Julia switching tool - the port of chruby. Eventaully this will be added as jlenv plugin, jlenv-chjl. Currently the jlenv and chjulia scripts have different
conventions/assumptions about where Julias are installed - these need to be
reconciled.
Likely released with the next major version of jlenv.
Any indication when the next version will be released? Right now jlenv-installer does not work (probably because it doesnât exist yet, the file is still called rbenv-installer in the repository). As an avid user of pyenv for Python Iâm really looking forward to using a tool for Julia that works in the same way.
Hmm, jlenv-installer is kinda ready - caveat emptor . Issue reports and PRâs welcome.
I think you meant jlenv-install plugin and that is not yet released. Sorry about that.
If you donât mind the bleeding edge try the jl branch in my repository of julia-install - this is what the jlenv-install plugin will invoke under the covers.
Alternatively, try the julia-build - linked to in the OP, that should work and wonât be changing except for bug reports and version releases.
Be forewarned that julia-build will be deprecated as soon as julia-install is ready (verifies source signatures), at which point the jlenv-install plugin will likely be ready too.
Feedback and issues reports welcome - PRâs too.
There are a few things that need to be in place before turning the jlenv-install plugin loose:
Internalising the correct way to manage Juliaâs packages across multiple version installs, and multiple users.
Are we going to support installing to system wide (-1), or rather just allowing point to a system install if asked to (+1). The issue of package management setup in the case of multiple users requires some thought.
Sync jlenv and chjulia and julia-install in terms of folder locations and package management
Ensure that jlenv, pyenv and rbenv donât stand on each others toes
I am curious how jlenv-install will keep a list of available julia versions. I think it would be beneficial to hook into the github api to get a list of the releases.
# with curl
curl -fsSL https://github.com/jlenv/jlenv-installer/raw/master/bin/jlenv-installer | bash
# alternatively, with wget
wget -q https://github.com/jlenv/jlenv-installer/raw/master/bin/jlenv-installer -O- | bash
Simply canât work: thereâs no jlenv-installer in that location (I know, I tried). And given the file has not been renamed, I have no guarantee that itâs been modified enough to be used, so I donât dare change the instructions to run rbenv-installer instead.
So I repeat my question: when can we expect jlenv-installer to be ready?
Perhaps an interesting balance would be writing a simple github bot that will make a pull request for every julia release. This way the versions are still loosely-coupled, but there is a level of automation that hopefully minimizes errors from human editing and minimizes the propagation time between a julia release and its availability in jlenv
TLDR; There is a script in jelnv/julia-versions/update.sh that you can use in some automagic chain with weiâs pull. This is out of jlenvâs scope for the reasons below.
Youâve correctly identified the jlenv is opinionated. The opinions are that only bash(other shells should work but YMMV - see test suite), HTTP and Git are required.
To be clear âthe opinions of jlenvâ right now is just me - until other contributors step forward. At that point things may change or fork as Linus intended.
From the perspective of what jlenv aims to achieve - minimally constrained users - that is a seismic imbalance: Youâve just tilted (imbalanced) everything toward github. jlenv aims to let you make your source of truth about Julia versions be any (gitlab/bitbucket) git repositry.
Again, not being tied to github, or git lab, etc etc and not being automated are features not a bugs.
In the TLDR Iâve pointed out how anyone who wants that sort of setup can achieve it. Jlenv wouldnât add anything worthwhile.
You are correct there is human dependent delay. Again that is a feature not a bug - think of the case where the human delay is \infty - equivalent to choosing to not make that version available.
Having said that, the intention of jlenv/julia-versions is to track Juliaâs releases - your fork of jlenv/julia-versions isnât bound by that, and you can still use jlenv confident your choices about what <your>/julia-versions contains will not adversely affect jlenvâs function. If jlenv/julia-versions isnât updating fast enough for you please make a PR for that version.
Right now julia-install doesnât allow you to point to another source of julia versions that it knows about - but it will in the fullness of time
Iâm a data scientist, not a developer, so not sure I can help with PRâs, but if I see any issues Iâll report them.
Just a quick question: you mention jlenv, rbenv and pyenv possibly standing on each otherâs toes. Iâm using pyenv already. Are there any specific things I should be on the lookout for?
As a general note, all these *env so far allow functions to be overridden - you can see this in the test suite where tests redefine some functions. IMO this is a no-no, and jlenv will eventually disallow this sort of âhijackingâ.
The only concrete issue I have been able to find where this might be the culprit is between rbenv and pyenv was not reproducable.
So strictly nothing yet that concerns jlenv, but I wouldnât be surprised if something like that prior experience popped up.
I should have expected it when I read that the script would first detect whether Homebrew was installed. I happen to use Linux Homebrew (one reason being that itâs the easiest way to install pyenv on Linux!). Is there any way bypass the test? And if not, what would you require to make jlenv available via Homebrew apart from time?
Wouldnât it? Wouldnât removing the test allow jlenv to be installed normally despite Homebrew being installed on my machine?
If you donât, why have the test in the first place? People canât just use Homebrew to install something that is not available as a Homebrew recipe in the first place. Since it seems youâre not planning to have jlenv available as a Homebrew recipe, why are you even testing for that option?
If other people want jlenv available as a Homebrew recipe, but you donât want to handle that yourself, let them package it themselves, and install it themselves using brew install jlenv. But you shouldnât have to worry about it in your own install script.
. Issue reports and PRâs welcome.