When working on a package MyPackage, I have so far also used MyPackage as my current environment. This seems to work well, for instance I can easily add package dependencies using ]add.
But sometimes, e.g. during debugging, I may temporarily need a package (e.g. Plots) that I don’t want to add to MyPackage, and also not to my default environment.
What is the best practice for this? Should I have a different environment specifically for the development of MyPackage, and then activate MyPackage only temporarily when working with its dependencies?
I personally have an environment, where the package(s) I develop are in development mode, I have revise and other debugging tools installed.
I actually only ever use a packages own environment to add (or remove) dependencies.
So yes, I do exactly as you write, I have a development environment for my package – or more precisely one where all packages from the ecosystem I mostly work on are in dev-mode.
Using MyPackage as your only environment or the one you activate, I would suggest putting MyPackage in @MyPackage and then you can install anything to your julia pkgs and include them or call using from the repl while your MyPackage is loaded. Keeps your environment clean and lets you access any features from other pkgs. You can make temp dirs with julia too or if your MyPackage is on git you can dev . your repo as well, you have alot of options for isolating things.
I also am not entirely clear on how to do it best. I make shared environments with development tools, works basically like a default environment but I can make as many for a Julia version as I want. If I activate another environment on top of it, I can load packages from either, with the risk of them disagreeing on a dependency’s version and doing weird things like triggering precompilation for a weird mix of environments (jkrumbiegel.com – Pkg.jl and Julia Environments for Beginners - Stacked Environments). Workspaces resolve projects together, but it doesn’t seem right to restrain a project with expendable plotting libraries. Tests and benchmarks, especially across a monorepo, are more justifiable because those validate the behavior of the package in the first place.
My package, ShareAdd.jl, adds tools to make working with shared/stacked environments more comfortable and now recognizes workspaces, too. With it, importing Plots is as easy as calling
@usingany Plots
If Plots is available anywhere in a shared environment, this works seamlessly. Otherwise, ShareAdd.jl would install it for you into the environment of your choice.
The problem of precompilation may still occur, of course: stacked environments can trigger invalidations when Julia resolves version conflicts dynamically. The alternative—putting Plots into your MyPackage directly or having them both in the same workspace—has its own drawbacks, however. In my personal experience, stacked environments with ShareAdd.jl generally work well enough.