There are some packages I mostly use while developing some package. These include, for example, JET.jl & Cthulhu.jl when I am debugging, a bunch of <: AbstractArray implementations (StaticArrays.jl, etc) when I want to test how generic and type stable an API is, etc.
I don’t want to add a bunch of packages to the “global” environment @v#.#. Obviously, I don’t want to add them to the package I am working on.
So what is the best solution? I thought of collecting a cluster of packages in a named environment that I put in the depot path, eg @debug for the debug tools. This I could then insert to LOAD_PATH on demand.
But I can see several practical issues:
not all Julia versions I am using would support the latest version of these tools. In fact, JET is closely tied to a specific Julia version.
I am not aware of tooling to manage LOAD_PATH. Of course I can use generic mutable vector functions, but a text-based gui would be nicer. Does that exist?
How do users manage this problem, ie keep an environment for development packages while keeping other environments clean?
For lightweight, generic tools like JET.jl and Cthulhu.jl, the global environment seems like a good choice. For other things like StaticArrays.jl, a shared environment like @debug seems more appropriate. At least that’s how I usually do it.
Just for the records, if those packages are part of the testing environment, TestEnv.jl is a useful tool. I have it in the global environment and find myself using it quite often now.
then just use them in package tests, and use TestEnv as @lmiq suggests to make them available in the REPL.
Other packages that are not needed for your package tests – temp envs just work in Julia, do using Cthulhu and Julia suggests installing it. For even more convenience, try BasicAutolods.jl – then, typing stuff like @descend_code_warntype ... would automatically ask if you want to install Cthulhu (can do it in a temp env).