ANN: mybinder.org support for Julia 1.x and Project.toml

I notice mybinder moved on to Julia 1.3.1. However, some packages fail there. Is it possible to pin the Julia version in the ipynb file (or Project.toml)? It seems that both [compat]julia=“1.1” and “kernelspec” (in ipynb) are being ignored…

Try julia = "=1.0.2" in the compat section, that should pin it to that version. julia = "1.1" means “the newest version that is compatible with 1.1 according to semver”. It really is just a lower bound on all 1.x.y versions.

The tilde specifier

julia = "~1.0"

is also an option to get [1.0.0, 1.1.0).

Great, seems to work now:-) Thank you very much for pointers!

1 Like

Great to hear that Binder can be used for Julia! Two questions:

  1. I am using the Project.toml file found here: demo-julia/Project.toml at main · binder-examples/demo-julia · GitHub

Do the strings to the right from “=” specify package versions? Where can these strings be found, i.e. if I need to add the Turing v0.6.23 package, how should the Project.toml be edited?

  1. I need Julia 1.0.4 and here is my Project.toml file: BNN_tox/Project.toml at master · elizavetasemenova/BNN_tox · GitHub
    However, when I launch the image, the version is 1.3.1

I think most of your questions can be answered by 3. Managing Packages · Pkg.jl, 4. Working with Environment · Pkg.jl and 6. Compatibility · Pkg.jl.

No, its just a unique identifier, UUID, that each package has, so it is not a version, just an “extension” of the name.

You would use the package manager to pkg> add Turing@0.6.23 and then also maybe add a [compat] entry. I believe that binder will use the Manifest.toml file, so consider committing that.

Yes, see the section about Compatibility I linked above: julia = "1.0.4" means [1.0.4, 2.0). See the docs for other alternatives.

Just to add, to chose specifically 1.0.4, the syntax is julia = "=1.0.4" (note the double equals).

1 Like

thanks for your answers! The picture is clearer now, but I still don’t understand a couple of things: my goal is to create an image with Julia 1.0.4 (or whatever version can do the right version of Turing) and Turing 0.6.23 to be able to share the environment for a publication. My current understanding is that if I manage to collect correctly Manifest.toml and Project.toml files, Binder will be launching exactly what I need and the users won’t need to make any additional installations. The questions now are:

  • where does the Manifest.toml file come from? I have found a couple on my computer, but none of them contains the Turing record, even though I use Truing all the time.
  • do the UUID come into Project.toml from the Manifest.toml file, i.e. should I copy-paste them from there for the libraries which I am going to use?
  • where and when should I use the package manager on Binder? I thought the idea of Binder was to pre-define all package versions in Project.toml and let everyone use the given set up. Please correct me if I am wrong.

thanks, with this correction I got version 1.0.4 to work!

1 Like

The Project.toml and Manifest.toml files, forming an environment, are automatically generated when you ] add packages. By default, Julia is using a global environment named after the Julia version you are using, e.g. v1.3, which lies in ~/.julia/environments/v1.3. To change the environment, you can start Julia with julia --project=. or, alternatively, use ] activate . inside the REPL. The dot here simply means the current directory (it could be any path). If you then ] add a package you will see that the local Project.toml and Manifest.toml in your current directory will change (or be created if they didn’t exist before). There will automatically be the correct UUID. No need to copy past it.

Therefore, to make your publication project self-contained, you should navigate to its root directory, start julia with julia --project=. and add all the relevant packages. Note that you can use ] add Turing@0.6.23 to add a specific version of Turing. Why was Turing working before? Because it is present in the global environment, which is, well, global and can always be accessed. Make sure that you check which other packages from the global environment you were using and add their respective versions to your local environment.

Afterwards, push your project with the toml files to GitHub. Binder will now “just work”. When creating a docker container, it automatically sees the toml files and installs all the dependencies (it calls ] instantiate for this). No need for “using the package manager on Binder”.

I hope this helps. Let me know if something is still unclear.

PS: See an example here: GitHub - carstenbauer/JuliaOulu20: Julia Workshop @ University of Oulu, Finnland

3 Likes

Thank you Carsten! Following your hint, I found the folder ~/.julia/environments/v1.0 and the Manifest.toml and Project.toml files in it - Binder works well with those two and does exactly what I want.

1 Like

Is there any way to put Manifest.toml and Project.toml in a sub-directory? My notebooks are not put at the root of my repo. So if I do Pkg.active(".") in a notebook, the .toml files are create where to notebooks are.

No, mybinder.org will only process a project in the root. But, notebooks in sub folders automatically activate such projects, I.e. you should not need the manual activate call in your notebook at all.

2 Likes

How to use myBinder with a package that allows multiple Julia versions in [compat], e.g. julia = "1.3,1.4,1.5" ?

I am now getting the following error in myBinder:

Error during build: invalid literal for int() with base 10: '1,1'

EDIT: This has been addressed in the jupyter discourse forum and resulted in a new issue being created on their repository: [Julia] myBinder build error ("invalid literal for int() with base 10") - #3 by sylvaticus - Binder - Jupyter Community Forum

I tried out Binder yesterday. Things seemed to work but when I evaluated the first cell it did using Queryverse which tried to precompile and failed due to some missing xlsx related stuff. It appears that the excel reading components rely on some python libraries that have to be separately installed? Is it possible to make that be installed in the docker image? What is required?

Yes I could do using ... For just the packages i actually need but I’m writing tutorials and I think the audience wants the simplicity of grabbing all of queryverse.

You probably need to add a requirements.txt (I think that is the Python way of doing this) that adds the xlrd library.

Although, I’m slightly confused now, I thought we had setup the binder story so that PyCall.jl would use a private conda Python installation, in which case xlrd should be auto-installed for you…

Well it didn’t work by automatic anything, but adding requirements.txt with

xlrd==1.1.*

did the trick

EDIT: However, it takes something like 15-30 minutes to build this binder… and it seems to rebuild most times I go to the link… I thought it was cached after the first build…

Yep, every time I go to my url I get a new build, it takes what seems like a half hour to start. Totally unusable.

Are you making any update to the github repo? That will trigger a rebuild. Otherwise that sounds like a bug on the mybinder side of things to me.

nope, repo has been static for several hours, but still every time I try to open it, it’s rebuilding.

Right now it’s only really got one ipynb which is something that does graphs of the covidtracking.org data across all the states, so my friends can just go and get the latest graphs and not ask me to manually update some other ones I was making in PDF form :wink:

There are some other notebooks for tutorials but I haven’t pushed the actual ipynb yet because I need some debugging etc. For example, it seems like Gadfly causes conflicts with recent Queryverse and with Turing… so I haven’t figured that out yet.

It actually opened literally instantaneously for me just now :slight_smile: I think whatever is going on there, it is a binder thing, not related to the Julia side of things.

1 Like