Terminology confusion: environment vs project

Hi, I’ve been using Julia’s Pkg for almost a year with plenty of success. However, I’m giving a presentation at my workplace on Julia workflow and package development next week and realized that I’m pretty confused about some terminology no matter how many times I read

What is the difference between a project and an environment? If I make a new directory, cd into it, and do activate ., have I created a project or an environment?

Does a stack of projects make an environment? Or is a stack of environments called a stacked environment?

My confusion is furthered a bit since https://julialang.github.io/Pkg.jl/dev/environments/ is title “Working with Environments”, but then proceeds to talk only about projects.

I appreciate any tips to help me with understanding how projects and environments relate/differ.

2 Likes

Also refer to https://julialang.github.io/Pkg.jl/v1/environments/

The way I understand it is projects are useful because they are associated with environments set up just so. Precisely the packages that one needs for the project, with the correct versions of each.

The way I would put it is that an environment is not necessarily associated with a project, but a project necessarily defines and environment. The environment of your project is described by the Project.toml in the project directory, but you can have a Project.toml in an environment not associated with a project. Such a Project.toml would have a [deps] section, but no header (the name Project.toml is perhaps confusing). The Manifest.toml works similarly: it can be used by your project environment, but it can also be used in an environment not associated with a project.

An environment defines a set of packages as dependencies, optionally with versions down to specific commits. This is true whether or not it’s associated with a project. For project environments, the project will use dependencies defined in its environment.

3 Likes

An environment is the whole set of things that tell you what import X means in different parts of your application. It’s a set of root packages and a dependency graph. (More technically, it is a mapping from top-level names to package UUIDs and a mapping from context UUID/dependency name pairs to dependency UUIDs.)

It’s only confusing because each project does define an environment but there are also other ways environments are defined. For example a directory with a bunch of packages in it also implicitly defines an environment by its file system layout. And the load path defines an environment created by stacking all the individual environments in the LOAD_PATH variable.

6 Likes

Thank you all for the responses! I think I understand. So to recap and try to answer my specific embedded questions above,

If I make a new directory, cd into it, and do activate . , have I created a project or an environment?

Both. This creates a project, which is a type of environment.

Does a stack of projects make an environment? Or is a stack of environments called a stacked environment ?

We aren’t limited to stacking projects only. We can stack environments (of any type), which creates a stacked environment. Some of the environments that compose this stack might be projects. Some might be other types of environments.

Are these answers true?

1 Like

Yes, you’ve got it.

1 Like