Avik, what happens with precompilation if .julia isn't writable? (Too chicken to try it out here.)
On Monday, November 16, 2015 at 4:30:34 AM UTC-8, Avik Sengupta wrote: > > .julia does not need to be writable for running Julia code. It needs to be > writable for package operations (add, update etc). I run a shared .julia on > a multiuser linux machine, it works well. The only issue is that doing > Pkg.update() is a bit of a pain, but we only do that very rarely. > > Regards > - > Avik > > On Monday, 16 November 2015 08:05:38 UTC, Sheehan Olver wrote: >> >> Another requirement is that the packages are shared across users, to save >> disk space. Gadfly + PyPlot + IJulia (with Conda.jl version of Jupyter) >> takes over 750MB. Does .julia need to be writable? If not, I guess both >> options are still possible. >> >> On Monday, November 16, 2015 at 2:05:45 PM UTC+11, Sheehan Olver wrote: >>> >>> >>> I'm trying to figure out the "best" way to create a stable version of >>> Julia + Gadfly + PyPlot + IJulia (+ other packages?) for a semester long >>> course. I don't want to have the students run Pkg.add(...)/Pkg.update(), >>> as packages have a tendency to occasionally break on updates, and it's a >>> headache dealing with this during the lecture. >>> >>> Two possible solutions I can think of of are: >>> >>> 1) Prebake a .julia folder that contains all the necessary resources, >>> with a script to reset in case the students break it with Pkg.update(). >>> 2) Use system image >>> >>> http://docs.julialang.org/en/release-0.4/devdocs/sysimg/ >>> >>> that includes all the necessary packages. It's not really clear how to >>> do this from the documentation, though. I'm also not sure how that would >>> interact with Pkg.update() though, so probably instructions to delete >>> .julia would also need to be given. >>> >>> >>> Any other options I'm missing? If 2 is recommended, any tutorial how to >>> do this? >>> >>
