One solution for universities that cannot pony up the use fees for juliabox could be to make it really easy for the instructor to set up the environment just the way the instructor wants it (with the packages that are required for the course, all precompiled and ready to go), and then to make a bundle out of that installation that can be easily transferred to the student’s computers. Perhaps such a thing is already possible?
If the computers have internet access and if you can let go of the “precompiled and ready to go” requirement, you could:
- create a fresh environment using
julia --project=.in a new folder, then add all the packages you’ll need for the class.
- distribute the
Manifest.tomlfiles that Pkg creates in that new directory to your students and ask them to run
julia --project=.in a directory containing the toml files, then
By distributing the
Manifest.toml in addition to the
Project.toml, everybody will be using the same versions of the packages (perhaps you could even
pin the packages), and you can also include unpublished packages containing course-specific code by just
pkg> adding them with a URL.
If having students precompile the code themselves is not an option, I think making a custom system image is the only option, which is a lot more involved.
True, I thought of that. However, I am wondering about the possibility of creating an installation like this and then zipping up all the files that such process generates. Would it be possible to unzip that folder tree and get a functional Julia installation? I will attempt to do this when I find some time, and report here. But perhaps someone has already tried this?
Maybe a Docker image could be a solution?
Has been a big success for this. You version a package and Manifest, and then in any code or jupyter notebook, you make a single call to activate itit (where it downloads and instnatuates if required)
Is there a simple explanation of how this works?
@arnavsood can fill in more details, but basically all it does is download a github repo with a project and manifest (if necessary) and activate it. If it hasn’t been downloaded before, it instantiates and precompiles.
So you just put the same line of code at the top of all notebooks. If you want to change a version of the package and Manifest, you just tag a different version in the repo.
Can one precompile in the build script, or is that a hack?
What build script are you referring to?
It’s a hack as far as I’m concerned! Precompile works best when called once, after every package got installed. If each package precompiles itself on build, it would likely lead to worse precompilation behaviour.
Why not just make your own depot, install all the packages you need within there (and instantiate or not depending on whether you want it to be tiny or huge), tar+gz or zip it and send it off to students? I don’t think you’re going to get around doing the initial precompile of all packages, but how much time does that really buy you anyway? 5 minutes maybe?
Edit: Note that making your own depot is as simple as running
JULIA_DEPOT_PATH=/my/depot/path julia and running
Delivering Julia code to production computers
@jlperla basically summed it up, but a few things worth mentioning on the
We have an option to put these packages into a user’s “default” environment (i.e.,
~/.julia/environments/v1.0) so that they can play around on their own without needing the custom code.
We have a
forceoption, so that if students ever mess up a given environment, they can easily do a “factory reset.”
You can use GitHub version information, corresponding to releases (or commits) of the TOML repo in question.
Happy to help out/explain in more detail if that would be useful.