# Using Julia on campus computers w cloud file storage

**URL:** <https://discourse.julialang.org/t/using-julia-on-campus-computers-w-cloud-file-storage/5157>\
**Category:** General Usage\
**Created:** [July 31, 2017, 7:55pm UTC](https://discourse.julialang.org/t/using-julia-on-campus-computers-w-cloud-file-storage/5157 "2017-07-31T19:55:08Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![John\_Gibson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/john_gibson/32/5321_2.png) [@John\_Gibson](https://discourse.julialang.org/u/John_Gibson)\
**Post date:** [July 31, 2017, 7:55pm UTC](https://discourse.julialang.org/t/using-julia-on-campus-computers-w-cloud-file-storage/5157/1 "2017-07-31T19:55:08Z")

</div>

How do people who teach Julia in the classroom reconcile Julia’s caching of packages in user-specific `$JULIA_PKGDIR` directories (e.g. `~/.julia`) with the lack of user-specific local storage on typical classroom computers?

I’ll be teaching an undergrad numerical methods course with Julia this fall. I’d like to the students to run Julia on the classroom computers (WIndows machines). But local disk space on these machines is nonuniform, unreliable, and unprotected, and the university strongly encourages students to store all their files on Box (the university’s cloud file-storage solution). I suppose I can tell students to sit at the same machines every day, find some local disk space, point their JULIA\_PKGDIR there, and rebuild their packages if they get wiped out. But this is not appealing solution.

I’d have them use JuliaBox except for the 500 MB disk space limit. I couldn’t even complete `Pkg.add("Plots")` on JuliaBox a few weeks ago. It reached the disk quota and crashed.

---

<div class="post-metadata">

**Author:** ![JaredCrean2](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jaredcrean2/32/3574_2.png) [@JaredCrean2](https://discourse.julialang.org/u/JaredCrean2)\
**Post date:** [July 31, 2017, 9:30pm UTC](https://discourse.julialang.org/t/using-julia-on-campus-computers-w-cloud-file-storage/5157/2 "2017-07-31T21:30:17Z")

</div>

It looks like you can mount Box storage as a network drive [like this](http://the-gadgeteer.com/2012/02/27/how-to-use-your-box-account-as-a-network-drive/) and have it automatically reconnect at login. If you have all your student do that an then set `JULIA_PKGDIR` to somewhere on the mapped drive, that could work (I assume student accounts can set their own environment variables on Windows, although I don’t know for sure).

If this works, could you do a quick measurement of package load times? I’m curious of the network will be a bottleneck.

---

<div class="post-metadata">

**Author:** ![avik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/avik/32/17_2.png) [@avik](https://discourse.julialang.org/u/avik)\
**Post date:** [August 1, 2017, 12:13am UTC](https://discourse.julialang.org/t/using-julia-on-campus-computers-w-cloud-file-storage/5157/3 "2017-08-01T00:13:29Z")

</div>

JuliaBox quota should be increased to 1GB soon, and we do larger quotas for custom environments for specific classes or universities.

The size of the Plots package is an unfortunate artefact… there are no easy solutions, but I do wish it could be fixed.

Regards

Avik

---

<div class="post-metadata">

**Author:** ![traktofon](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/traktofon/32/591_2.png) [@traktofon](https://discourse.julialang.org/u/traktofon)\
**Post date:** [August 1, 2017, 5:44am UTC](https://discourse.julialang.org/t/using-julia-on-campus-computers-w-cloud-file-storage/5157/4 "2017-08-01T05:44:13Z")

</div>

When using cloud storage to host the Julia package directory, you might run into similar problems as recently discussed in this thread:

> [@Julia Hangs After Attempt at Pkg.add("") in Linux Cluster](https://discourse.julialang.org/t/julia-hangs-after-attempt-at-pkg-add-in-linux-cluster/4320):
>
> Hi all, I’m not new to Julia, but I’m certainly new to running it in a Linux cluster. I’m a neuroscientist and recently needed to run some computation heavy simulations written in Julia in my school’s Linux cluster. The cluster didn’t have Julia available as a module, so I had to download the 64-bit Linux binary to my personal environment in the cluster. From Julia’s command line interface in the cluster, I attempted to run Pkg.add(“Plots”) To my surprise, there was no print output from Juli…

Because I guess cloud storage has similar (or worse) latency as NFS, which makes operating on many small files, like git does, painfully slow. One solution that was suggested in that thread is to use this package

> **[GitHub - KristofferC/Pkg25.jl](https://github.com/KristofferC/Pkg25.jl)**
>
> Contribute to KristofferC/Pkg25.jl development by creating an account on GitHub.

for speeding up the `Pkg` operations. Though personally I haven’t tried that out.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [August 1, 2017, 5:59am UTC](https://discourse.julialang.org/t/using-julia-on-campus-computers-w-cloud-file-storage/5157/5 "2017-08-01T05:59:29Z")

</div>

> [@avik](#):
>
> The size of the Plots package is an unfortunate artefact… there are no easy solutions, but I do wish it could be fixed.

It will be fixed by Pkg3 since we’ll have to re-tag everything. Essentially, the problem which effects Plots.jl and DifferentialEquations.jl in a big way is that they used to have their documentation (which included animations) as part of the repository, along with IJulia notebooks. This was found to bloat the size of the repo, so these were subsequently moved to separate docs-only repos within the orgs. However, deleting these things from the code doesn’t actually delete it from the repository because it stays in the Git history (which is what really causes the bloat in the first place), so now these repos have 100+MB repos almost entirely due to the .git history. You can clean these histories by using [a repo cleaner](https://rtyley.github.io/bfg-repo-cleaner/), but [that will break every tag in METADATA](https://github.com/JuliaDiffEq/DifferentialEquations.jl/issues/107). So instead we have to wait until Pkg3 makes a new METADATA, and then these repos (and any other repo which had the same issues) drop in size by 100MB.

Moral of the story is that if you plan on continued development, put the docs in a separate repo, and when the new METADATA comes repo cleaners will be applied to these big libraries and this will fix the size issues for good.

But sorry @John_Gibson that won’t help for the fall. But it does suggest that another solution would be to copy (but not fork! you don’t want the git history) the Plots.jl `src`, `deps`, and `test` to a new repo and have students clone that. In that case, you’d get the “same repo” but it will be only 3MB. You wouldn’t get any updates unless you manually pull them in, but maybe it’s helpful to just solidify a version for teaching purposes anyways. If you do this, make sure you acknowledge the original repo in the license.