liveBook · Manning

Environment

As explained in Julia as a Second Language

A package environment is a configuration context that records package availability, versions, dependencies, and source locations for a Julia session.

An environment is a work area that determines which packages a Julia session can use. Keep separate environments when projects need different packages or versions: a stable setup for a job need not constrain a hobby project that uses newer features. section 16.1 section 16.6

Switch between project setups

Create directories named `job` and `hobby`. In the Julia REPL, press `]` for package mode, then run `activate job`. The prompt changes to `(job) pkg>`, indicating which environment subsequent package commands will modify. Use `add CairoMakie@0.5.10` to request a particular version and `status` to check the packages recorded there. Activate `hobby` to maintain a different setup. section 16.1

Package commands change the active environment: `add` records a dependency, `rm` removes one, and `status` lists what is available. `Project.toml` records direct dependencies; `Manifest.toml` records resolved dependency information, including packages those dependencies need. A package is itself an environment, so activate its directory before adding dependencies meant for that package rather than for your everyday work area. section 16.1 section 16.2.1

(hobby) pkg> activate ToyGeometry/
 Activating project at `~/dev/hobby/ToyGeometry`

(ToyGeometry) pkg> add Dates Base64
  Resolving package versions...
   Updating `~/dev/hobby/ToyGeometry/Project.toml`
 [2a0f44e3] + Base64
 [ade2ca70] + Dates
   Updating `~/dev/hobby/ToyGeometry/Manifest.toml`
 [2a0f44e3] + Base64
 [ade2ca70] + Dates
 [de0858da] + Printf
 [4ec0a83e] + Unicode

(ToyGeometry) pkg> status
    Project ToyGeometry v0.1.0
     Status `~/dev/hobby/ToyGeometry/Project.toml`
 [2a0f44e3] Base64
 [ade2ca70] Dates

Activating `ToyGeometry` before adding `Dates` and `Base64` puts them in the package’s own environment. The resulting manifest also lists `Printf` and `Unicode`, illustrating dependencies brought in indirectly. section 16.2.1

A nearby package directory is not automatically available to `using`: Julia does not search the current filesystem path for packages. During local development, return to the working environment and run `dev ./ToyGeometry`. That records where the package lives so the environment can load its changing code. Keep development aids such as `Revise` in the working environment rather than adding them as dependencies of the package being built. section 16.3

The same separation applies to tests: a package’s test directory has its own environment, allowing test-only dependencies to stay out of the package’s main dependencies. section 16.6

How Julia as a Second Language covers it

How deep it goes
Works through activation, package commands, dependency files, and local development; does not detail package resolution internals.
Examples
Uses separate job and hobby setups, then activates a geometry package and develops it from a local path.
What it assumes
Builds on familiarity with the Julia REPL and modules while teaching package-mode environment commands through examples.
What you can do after
Operate/configure it with `activate`, `add`, `rm`, `status`, and `dev` to manage project and package dependencies.
How it connects
Connects environments to packages, modules, direct and indirect dependencies, and package tests.
Cover of Julia as a Second Language
liveBookmanning.com
Read Julia as a Second Language on liveBook Get the book at manning.com

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Julia as a Second Language. The section links point to the parts of the book it draws on.