My question is basically, to those who are teaching Julia currently, how are you going about setting the fundementals up (ie. software) to ensure that your students (with no previous programming experience) gets a plesant experience? So like are you;
- Providing them with some kind of installation guide?
- Using some kind of server/webapplication to let the students use Julia?
- Do you provide them with a .zip file holding the release of Julia / GUI etc.?
Currently I am not interested in what kind of topics you usually teach, but just your approaches to setup an enviroment which makes it easy for the students to start using Julia.
I hope my question is clear enough, basically I just want to know what kind of setups you used and which you found succes/failure with and so forth.
I have not yet teach Julia, but I have teach Python for scientific field, and in my opinion a good option for Julia could be:
- Give them the last version in a zip to install them ( but it is because sometimes). It is important depending of the Internet velocity. In the julia case, you can provide them a julia environment with the packages. Another option could be a virtual machine or docker.
- The Jupyter environment is good enough for teaching, you can recommend an IDE but for a more interactive teaching using IJulia could be enough.
Containers! The best would likely be to get a solid battle-tested good container for the students to use. On that note, make sure they all use contained environments per project.
I think that setting up a Jupyter server, preferably in-house, is the best way to do this.
You can of course also allow/recommend that students use their own machines, with their favorite IDE etc, but there should be an environment that Just Works.
What is a container? Could you explain it a bit, and link to some good ressources?
Yes, I also really liked that Jupyter allowed to include text / code etc. but it seemed to run a bit slow sometimes. I think a good balance would be to teach using Jupyter and then letting students utilize Julia on their own machine, using some kind of predecided interface.
Docker is a good choice, but config a docker with pre-installed packages is pretty painful, I’m currently using a self-made container to calculate my data, but there always be a bunch of problem (related to permission problem)…
Checkout the official docker: https://hub.docker.com/_/julia
I don’t see why, you just install them in the
Dockerfile like everything else.
If you are trying to build a docker that include R/Julia/Python 3.7/MATLAB at the same time with commonly used packages, things will be really painful…
Say, the problem I met:
I want to build a docker with the following packages preinstalled:
GLM DSP FFTW RCall etc…, so i built the following script:
for pkg in Pkg.installed()
pkgsym = Symbol(pkg)
It’s pretty straight forward, install the package via
RUN install2.jl FFTW RCall RData Glob DataFrames Parameters JLD Suppressor MultivariateStats
now everything is installed and pre-compiled, but you’ll met permission problem if not using root user while loading the packages in your script, so we need:
RUN chmod -R ugo+r+x /usr/local/julia-1.1.1
Everything works well until you tried to install some packages that dependent on these pre-installed packages, there will be errors, and I have to install the package with
sudo julia. And loading the package while you don’t have super user permission, there’ll be new problem.
I don’t know how the package manager works, but I really met a bunch of problems
I don’t know about Matlab, but R is prepackaged for eg Ubuntu/Debian, and all the other distros, Python ditto, and downloading and extracting Julia is straightforward.
In any case, the suggestion was about creating a Docker image with Julia, which is fairly simple.
Either use the docker image as the default (root) user (it’s a sandbox, can’t do any harm), or create a user and install Julia as that user.
Creating a Docker image with a preinstalled & precompiled set of Julia packages is something that should be fairly easy for an IT department that otherwise uses Docker.
The idea is to have reproducible environment readily accessible for each of the students so all the kinks can be worked out consistently (e.g., permissions, path to installing packages, etc.). As an added benefit, it is something widely used in research labs, academia, industry, and such. There is a bit of an investment to figure out the right image to use. From the latest community surveys, a very small percent of the downloads were from Docker. My research lab is currently working on improving the images we use for development in Julia. UVA uses the
which allows to spawn interactive apps such as Jupyter lab and RStudio (it also allows local authentication which makes our data architecture person happy ). I have opened an issue for including other IDE such as Atom and VS Code which would make developing in Julia even nicer, but Jupyter lab is commonly used for teaching. Another example of using containers for teaching with Julia is from QuantEcon
Thanks for the explanation! Exciting to hear how others do it. I will keep these different approaches in mind for the future.
Thanks for the hint!
For future readers, here’s a link to the relevant section of the relevant QuantEcon lecture: https://lectures.quantecon.org/jl/more_julia/tools_editors.html#Docker
IMO, containers are the worst thing to do since it’s shielding the both the students and yourself from reality. Instead, have them install Julia and use Julia with the online instructions. Are the online instructions giving your students trouble? Change them by PRing to:
See an issue with the documentation? Change it by PRing to:
Are there not enough tutorials for the packages you’re interested in? Write one. Package doesn’t install on the first try? PR to fix it (or at least open a very good issue describing exactly what the error is so that way others who get it know what it is!).
IMO, this is easier to do than getting a Docker running anyways.
Couldn’t agree more. For our Julia based lectures and Julia workshops we switched from a boxed solution to having students install Julia and Jupyter themselves. Although there are always individual problems in the beginning (which are mostly related to python as we use PyPlot.jl), it really pays off in the long run for both students (and teachers). Most importantly, they will be able to scale their Julia computations; to a supercomputer for example.
(EDIT: We created instruction videos and pdfs for all OSs (in german))
Generally I agree with this attitude, but
the required improvements to make everything super easily and robustly installable may be beyond the resources of a few individuals within a short timeframe, so this is not practical for a course starting in the near future,
glitches do happen despite best efforts, and the instructor & TAs may not have the resources to deal with them.
Most university courses which teach some kind of programming make at least one supported working environment available, on machines managed by the institution. A Jupyter server, or some kind of an environment using a Docker image is a possible implementation for this (both require some work from IT though).
If, in addition, some students prefer to install Julia on their own machines, that is a win-win situation since they free resources (running Jupyter with tons of parallel users can be demanding). But having a fallback option that is under institutional control, works 99% of the time, and gets support from IT is also valuable.
FWIW, we make sure that everything is preinstalled and running in the computer pool of the institute as a backup (which is easy because there are admins that do 90% of the work and all computers are identical).
Let me say that I think that container solutions often are even more work on the instructor / TAs shoulders since a) it takes quite some time to create the container and b) if something doesn’t work / is missing they are the only ones who can fix things.
Here’s our Julia+Anaconda container, is being actively used by quite a few people:
Source for latest version is here:
There’s versions with and without CUDA. We build with Docker, and run with Singularity, Shifter or Docker, depending on environment.are
Actually, our users use this (more project-specific) container
It’s built on top of the aforementioned “mppmu/julia-anaconda” container.
In my experience containers are the “reality” and working on local machines more of the exception. At least in many fields it is pretty standard to use containers for most of the work especially for a wide range of security level environments. It is also pretty common to use containers for accessing computing power (big memory, big parallel, high computing, etc.) It may be a combination of experiences, but I don’t think the premise that containers are not used in “reality” hold.