Workflow for development packages

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:

  1. 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.

  2. 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?

2 Likes

Would ShareAdd.jl work for your setting?

3 Likes

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.

4 Likes

@SteffenPL: Yes, ShareAdd is kind of like what I am looking for. Thanks!

1 Like

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.

5 Likes

Sounds like you should add them to the test env,

] activate test
] add StaticArrays

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).

1 Like

Yes, TestEnv.jl is great, but my use case in the OP is for packages that are not in the test environment — debugging and exploratory use.

Certainly, but that comes with a time delay (even if the package itself is cached, the package manager may check the registry for the latest version).

Add

import Pkg
Pkg.UPDATED_REGISTRY_THIS_SESSION[] = true

to your startup.jl. That’s the setting created exactly to avoid all these implicit registry updates.