# Unsatisfiable requirements generated by two unrelated local packages

**URL:** <https://discourse.julialang.org/t/unsatisfiable-requirements-generated-by-two-unrelated-local-packages/69052>\
**Category:** Package Management\
**Created:** [October 1, 2021, 3:02pm UTC](https://discourse.julialang.org/t/unsatisfiable-requirements-generated-by-two-unrelated-local-packages/69052 "2021-10-01T15:02:13Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jack\_Coughlin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jack_coughlin/32/28571_2.png) [@Jack\_Coughlin](https://discourse.julialang.org/u/Jack_Coughlin)\
**Post date:** [October 1, 2021, 3:02pm UTC](https://discourse.julialang.org/t/unsatisfiable-requirements-generated-by-two-unrelated-local-packages/69052/1 "2021-10-01T15:02:13Z")

</div>

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

```julia
(@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!

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [October 1, 2021, 4:12pm UTC](https://discourse.julialang.org/t/unsatisfiable-requirements-generated-by-two-unrelated-local-packages/69052/2 "2021-10-01T16:12:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [October 1, 2021, 5:45pm UTC](https://discourse.julialang.org/t/unsatisfiable-requirements-generated-by-two-unrelated-local-packages/69052/3 "2021-10-01T17:45:13Z")

</div>

> [@Jack\_Coughlin](#):
>
> However, it seems that when I `dev .` them (for Revise), they get installed to the global environment.

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.