# ANN: julia-build, jlenv, jlenv-plugins and jlenv-cookbook

**URL:** https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528
**Category:** Tooling
**Created:** [October 31, 2019, 8:58am UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528 "2019-10-31T08:58:18Z")
**Posts on this page:** 16
**Page:** 1

<div class="post-metadata">

### Author: ![taqtiqa-mark](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taqtiqa-mark/32/4383_2.png) [@taqtiqa-mark](https://discourse.julialang.org/u/taqtiqa-mark)
#### Post date: [October 31, 2019, 8:58am UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/1 "2019-10-31T08:58:18Z")

</div>

# 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](https://www.github.com/jlenv/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.

More information about jlenv is [here](https://jlenv.github.io/jlenv/)

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](https://www.github.com/jlenv/) GitHub page.  
These projects have test suites that pass.

1. [jlenv](https://www.github.com/jlenv/jlenv)
2. [jlenv-vars](https://www.github.com/jlenv/jlenv-vars)
3. [jlenv-each](https://www.github.com/jlenv/jlenv-each)
4. [jlenv-update](https://www.github.com/jlenv/jlenv-update)
5. [julia-build](https://www.github.com/jlenv/julia-build)

### Forthcoming/Underway

[jlenv-cookbook](https://www.github.com/jlenv/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](https://www.github.com/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](https://www.github.com/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](https://www.github.com/jlenv/jlenv-installer):  
This is a install convenience script.  
Likely released _with_ the next major version of jlenv.

[chjulia](https://www.github.com/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.

---

<div class="post-metadata">

### Author: ![tsela](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tsela/32/52174_2.png) [@tsela](https://discourse.julialang.org/u/tsela)
#### Post date: [November 25, 2019, 2:03pm UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/2 "2019-11-25T14:03:28Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![taqtiqa-mark](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taqtiqa-mark/32/4383_2.png) [@taqtiqa-mark](https://discourse.julialang.org/u/taqtiqa-mark)
#### Post date: [November 25, 2019, 9:20pm UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/3 "2019-11-25T21:20:30Z")

</div>

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](https://github.com/taqtiqa-mark/julia-install/tree/jl) - 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

Hope that helps.

---

<div class="post-metadata">

### Author: ![mileslucas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mileslucas/32/11747_2.png) [@mileslucas](https://discourse.julialang.org/u/mileslucas)
#### Post date: [November 26, 2019, 7:46am UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/4 "2019-11-26T07:46:46Z")

</div>

@taqtiqa-mark

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.

---

<div class="post-metadata">

### Author: ![taqtiqa-mark](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taqtiqa-mark/32/4383_2.png) [@taqtiqa-mark](https://discourse.julialang.org/u/taqtiqa-mark)
#### Post date: [November 26, 2019, 6:31pm UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/5 "2019-11-26T18:31:35Z")

</div>

> [@mileslucas](#):
>
> I am curious how jlenv-install will keep a list of available julia versions.

> **[GitHub - jlenv/julia-versions: A common repository of Julia version metadata](https://github.com/jlenv/julia-versions)**
>
> A common repository of Julia version metadata. Contribute to jlenv/julia-versions development by creating an account on GitHub.

> [@mileslucas](#):
>
> I think it would be beneficial to hook into the github api to get a list of the releases.

You probably are right. I prefer loosely coupled systems, and eventually I’d like that `julia-install` could be pointed at a configurable endpoint:

1. Allows the community to have a fallback/DR source
2. Allow an organization to control what versions are available to be installed.
3. HTTP & Git protocols are the only requirements

So tying to GitHub’s API works against those objectives - at least makes them harder and constrains choices.

Hope that makes sense?

---

<div class="post-metadata">

### Author: ![tsela](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tsela/32/52174_2.png) [@tsela](https://discourse.julialang.org/u/tsela)
#### Post date: [December 4, 2019, 12:18pm UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/6 "2019-12-04T12:18:21Z")

</div>

Eh no, I _do_ mean `jlenv-installer`. Check the repository yourself: [https://github.com/jlenv/jlenv-installer/tree/master/bin](https://github.com/jlenv/jlenv-installer/tree/master/bin). No `jlenv-installer` file present, only an `rbenv-installer`. So the instructions given:

```julia
# 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?

---

<div class="post-metadata">

### Author: ![taqtiqa-mark](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taqtiqa-mark/32/4383_2.png) [@taqtiqa-mark](https://discourse.julialang.org/u/taqtiqa-mark)
#### Post date: [December 4, 2019, 5:29pm UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/7 "2019-12-04T17:29:49Z")

</div>

Apologies. Try now. Please note:

1. As with all these `curl | bash` type scripts - read it before you run it.
2. Also there are as yet no tests in this repo - PR’s welcome.

Hope that helps?

---

<div class="post-metadata">

### Author: ![mileslucas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mileslucas/32/11747_2.png) [@mileslucas](https://discourse.julialang.org/u/mileslucas)
#### Post date: [December 6, 2019, 12:20am UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/8 "2019-12-06T00:20:52Z")

</div>

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

---

<div class="post-metadata">

### Author: ![taqtiqa-mark](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taqtiqa-mark/32/4383_2.png) [@taqtiqa-mark](https://discourse.julialang.org/u/taqtiqa-mark)
#### Post date: [December 6, 2019, 4:55am UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/9 "2019-12-06T04:55:48Z")

</div>

TLDR; There is a script in [jelnv/julia-versions/update.sh](https://github.com/jlenv/julia-versions/blob/master/update.sh) that you can use in some automagic chain with wei’s [pull](https://github.com/wei/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.

> [@mileslucas](#):
>
> Perhaps an interesting balance would be writing a simple github bot

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.

> [@mileslucas](#):
>
> 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

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 😉

---

<div class="post-metadata">

### Author: ![tsela](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tsela/32/52174_2.png) [@tsela](https://discourse.julialang.org/u/tsela)
#### Post date: [December 10, 2019, 1:30pm UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/10 "2019-12-10T13:30:30Z")

</div>

Thanks! I’ll try it out.

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?

Cheers, and thanks for your hard work!

---

<div class="post-metadata">

### Author: ![taqtiqa-mark](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taqtiqa-mark/32/4383_2.png) [@taqtiqa-mark](https://discourse.julialang.org/u/taqtiqa-mark)
#### Post date: [December 11, 2019, 2:32am UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/11 "2019-12-11T02:32:08Z")

</div>

> [@tsela](#):
>
> 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.

---

<div class="post-metadata">

### Author: ![taqtiqa-mark](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taqtiqa-mark/32/4383_2.png) [@taqtiqa-mark](https://discourse.julialang.org/u/taqtiqa-mark)
#### Post date: [December 12, 2019, 12:48am UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/12 "2019-12-12T00:48:53Z")

</div>

> [@tsela](#):
>
> if I see any issues I’ll report them.

That would be appreciated.

---

<div class="post-metadata">

### Author: ![tsela](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tsela/32/52174_2.png) [@tsela](https://discourse.julialang.org/u/tsela)
#### Post date: [December 18, 2019, 2:09pm UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/13 "2019-12-18T14:09:52Z")

</div>

Frak!

> $ curl -fsSL [https://raw.githubusercontent.com/jlenv/jlenv-installer/master/libexec/jlenv-installer](https://raw.githubusercontent.com/jlenv/jlenv-installer/master/libexec/jlenv-installer) | bash  
> Installing jlenv with Homebrew not yet ported. Contributors needed…  
> bash: line 84: : command not found

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?

---

<div class="post-metadata">

### Author: ![taqtiqa-mark](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taqtiqa-mark/32/4383_2.png) [@taqtiqa-mark](https://discourse.julialang.org/u/taqtiqa-mark)
#### Post date: [December 24, 2019, 11:18pm UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/14 "2019-12-24T23:18:50Z")

</div>

**Disclosure:**  
I know nothing about the MacIntosh world - apart from it being insanly expensive.

> [@tsela](#):
>
> Is there any way bypass the test?

By passing the test wouldn’t fix anything would it?

> [@tsela](#):
>
> And if not, what would you require to make jlenv available via Homebrew apart from time?

Happy to bypass the test if you can explain/describe/document how another user would use homebrew with the test circumvented.

I don’t foresee doing whatever it is Homebrew needs to install and manage jlenv.

Am very happy to accept PR’s and answer questions.

---

<div class="post-metadata">

### Author: ![tsela](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tsela/32/52174_2.png) [@tsela](https://discourse.julialang.org/u/tsela)
#### Post date: [January 3, 2020, 9:30am UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/15 "2020-01-03T09:30:22Z")

</div>

> [@taqtiqa-mark](#):
>
> **Disclosure:**  
> I know nothing about the MacIntosh world - apart from it being insanly expensive.

Me neither. Like I said, I’m running Linux. I just happen to have the _Linux_ version of Homebrew installed ([Homebrew on Linux — Homebrew Documentation](https://docs.brew.sh/Homebrew-on-Linux)).

> [@taqtiqa-mark](#):
>
> By passing the test wouldn’t fix anything would it?

Wouldn’t it? Wouldn’t removing the test allow jlenv to be installed normally despite Homebrew being installed on my machine?

> [@taqtiqa-mark](#):
>
> I don’t foresee doing whatever it is Homebrew needs to install and manage jlenv.

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.

---

<div class="post-metadata">

### Author: ![taqtiqa-mark](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/taqtiqa-mark/32/4383_2.png) [@taqtiqa-mark](https://discourse.julialang.org/u/taqtiqa-mark)
#### Post date: [March 20, 2020, 3:15am UTC](https://discourse.julialang.org/t/ann-julia-build-jlenv-jlenv-plugins-and-jlenv-cookbook/30528/16 "2020-03-20T03:15:51Z")

</div>

This has been bugging me - I’ve decided to remove all ‘support’ for any package managers. I think that will resolve your issue.

Note sure when I’ll have time to get to this. PR’s welcome.
