Julia – Environments – Global vs project

Global installs are convenient, with packages available to any Julia program you run. Some workflows benefit from a “heavy” global environment with most common packages installed there DataFrames.jl, CSV.jl, XLSX.jl, Makie.jl, Distributions.jl and universally available to every project, with project-specific installs limited to specialized needs.

On the other hand, the lack of isolation between global and project-specific environments can result in globally-installed packages leaking into project tests, dependency chains, and so on. Workflows incorporating software engineering best practices typically benefit from having light global environments and heavy project environments: little to no packages installed globally, with all packages installed into project specific environments.

I prefer and recommend the latter approach, not just due to my software developer vocation, but also for robustness and replicability.

One way to achieve both the convenience of a global with just a little more friction is to created a dedicated scratch environment into which you can dump all the commonly used packages useful for many tasks and workflows before anything “escalates” into a fully-siloed project.

alias jc='julia --project=~/.julia-gpc`

This, as a full-fledged isolated environment, then gains the benefit of actually being able to be loaded up with useful packages, from fundamentals (e.g., DataFrames.jl, CSV, etc.) to more specialized domain-specific yet project-general ones (e.g. visualization libraries).