Unsatisfiable requirements generated by two unrelated local packages

Tooling Package Management
1

I have a pair of local packages that I am working on in parallel, call them LocalA and LocalB. Just now I entered a new REPL and executed ] dev . on LocalA, hoping to use a Revise.jl workflow with it in the REPL. This gives an unsatisfiable package requirements error, where the gist is that:

  • LocalA depends on Flux.jl, which is restricted by Colors.jl (???) to versions 0.10.2-0.12.6
  • Colors.jl is required by ProfileSVG.jl, which is required by LocalB

I gather that when I run

(@v1.6) pkg> dev .

that the current active environment is the global v1.6 environment, where LocalA and LocalB can create package conflicts between each other if they are both installed there. However, I have no interest in installing LocalA and LocalB to the global v1.6 environment. I only ever want to work on them in isolation, and they should never interact. Both LocalA and LocalB have their own project environments. However, it seems that when I dev . them (for Revise), they get installed to the global environment. And of course activate .; dev . fails with has the same name or UUID as the active project.

My question:

  • Is my assessment of the situation correct?
  • What am I doing wrong?

To me it seems like the most natural possible workflow that you would want to develop a package within the context of its own environment, so the fact that this is not possible suggests that I have a total misunderstanding of the behavior of one or both of activate and dev.

Thanks for any help!

2

You probably don’t want to use dev . at all here - simply activate . suffices. Activating the environment of e.g. LocalA already makes using LocalA possible. Additionally trying to do dev . would be like trying to add a package to itself as a dependency.

Frankly, I’m not sure what the use case for dev with a local path is - as I understand it, its use lies in copying a package to a local development folder to use a custom local version/fork instead of the one provided from a registry. So you’d use it like dev PkgAB and then you can hack on a local copy of PkgAB, located in the main julia directory if my memory serves right.

1 Like
3

If you dev them from the global environment they get installed in that environment; that’s kind of the idea of that operation. But you don’t need to do that for Revise. If you have Revise installed in the global environment and activate the package you want to work on, Revise will be available thanks to the “stacked environments” feature of Pkg.

2 Likes