Workflow for forking an environment

I have a “main” environment that has a lot of the packages I use. Whenever I want to try something out, I go to a new directory and I want to use those packages plus a couple of other packages.

  • I don’t want to reinstall these main packages
  • I don’t want to mutate-in-place the main environment with the new packages
  • I want the project’s Project.toml and Manifest.toml to be complete, not relying on some external hidden state

Is it possible to get all three of these criteria? If not, how close can I get?

1 Like

I tend to do a workflow pattern like this:

  1. Activate default environment
  2. Install packages I want available across all environments (for me, TerminalPager, IJulia, Revise, etc.)
  3. Navigate to other project where I want to do things
  4. Activate environment within the other project
  5. Add packages you want for that specific project
  6. Feel free to now use packages from the global separate environment and local project environment (any locally added packages are then written to the Project and Manifest tomls within that local environment)

I think that at least tackles your first two points although I am not sure about your third criterion.

I do that for packages like Revise, where I don’t want them in the Project.toml at all. But here I’m talking about packages like CairoMakie which

  • I want to use in many projects, and
  • want it to be part of the Project.toml,
  • but don’t want to wait for several minutes of installation.

Like this:

I see. I often create another global environment called something like pkg> activate @DATASCIENCE (or something shorter) and then add packages (like CSV, Arrow, DataFrames, Makie, CairoMakie). Then, when I want to do quick analyses, I just drop into that environment. If I need something else specific, I deactivate that global environment and then activate the project environment, add the needed packages, use it, and then carry on my way. There should be a more elegant way of switching “main” environments, but this is the best workaround I have found.

Check this attempt: GitHub - feanor12/Draft.jl: A small package to automatically create temporary environments in offline mode.

I think there are good ideas there.

2 Likes

The most straightforward solution is to copy the original project and manifest toml files into a new location and activate them there, but it would be nice if there was a shortcut for that. Then when adding new packages using the preserve-all flag to prohibit version changes.

3 Likes

This often triggers re/pre-compilation though because you’re using packages from different environments (which haven’t been resolved together)

Also, it breaks reproducibility for the same reason.