Not easy to add utility packages to env

General Usage Performance
21

A potentially cleaner workflow is to run this kind of code (like plotting) not in the package environment, but in a totally different one - temporary, if that’s a one-off task.

First, add insert!(LOAD_PATH, 2, mktempdir()) to startup.jl. I wish this was the default, or at least promoted more!

Then in REPL:

julia> using Plots
 │ Package Plots not found, but a package named Plots is available from a registry. 
 │ Install package?
 │   (@v1.8) pkg> add Plots 
 └ Select environment:
 > 1: `/tmp/jl_qN95JI` (/tmp/jl_qN95JI)
   2: `~/.julia/environments/v1.8/Project.toml` (@v#.#)
# press enter, Plots are now installed in a temp env

(jl_qN95JI) pkg> dev .  # assuming you started REPL in the package directory

julia> using YourPackage

# profit!
22

Excellent point here. In my own use case, the global packages are not dependencies of the package I’m working on, they are only convenience for debugging, data exploration, etc.

In this workflow, global package compatibility wont affect the deployed package.

23

The issues with stacking environments is what I was trying to avoid with my add --copy @utils suggestion earlier. Something that has 90% of the convenience of stacking a group of packages into your current env (whether a temporary one, in a debug folder, etc.) but without the reproducibiilty dangers.