# Package version conflicts

**URL:** <https://discourse.julialang.org/t/package-version-conflicts/92047>\
**Category:** General Usage\
**Created:** [December 23, 2022, 1:53pm UTC](https://discourse.julialang.org/t/package-version-conflicts/92047 "2022-12-23T13:53:59Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![erlebach](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/erlebach/32/12973_2.png) [@erlebach](https://discourse.julialang.org/u/erlebach)\
**Post date:** [December 23, 2022, 1:53pm UTC](https://discourse.julialang.org/t/package-version-conflicts/92047/1 "2022-12-23T13:53:59Z")

</div>

If two packages, say, Flux.jl and Lux.jl, included different versions of Zygote.jl, would this be an issue? Manifest.jl appears to only list one version of each module. What happens in this case? Thanks.

```
Gordon

```

---

<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:** [December 23, 2022, 1:56pm UTC](https://discourse.julialang.org/t/package-version-conflicts/92047/2 "2022-12-23T13:56:33Z")

</div>

If they are compatible with a common version of Zygote, version resolution would choose one which works with both. If not you would get an error from the version resolution. There is no way to load two different versions of the same package in the same Julia process.

---

<div class="post-metadata">

**Author:** ![erlebach](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/erlebach/32/12973_2.png) [@erlebach](https://discourse.julialang.org/u/erlebach)\
**Post date:** [December 23, 2022, 2:31pm UTC](https://discourse.julialang.org/t/package-version-conflicts/92047/3 "2022-12-23T14:31:26Z")

</div>

That is what I thought. That makes it increasingly difficult to maintain compatibility as the number of packages increases. It would be nice to have a list of stable packages with changes that happen on a much slower time scale.

---

<div class="post-metadata">

**Author:** ![Paulo\_Jabardo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paulo_jabardo/32/3196_2.png) [@Paulo\_Jabardo](https://discourse.julialang.org/u/Paulo_Jabardo)\
**Post date:** [January 2, 2023, 12:55pm UTC](https://discourse.julialang.org/t/package-version-conflicts/92047/4 "2023-01-02T12:55:10Z")

</div>

I really recommend you use environements. For each project/package you are developing, use a distinct environment and most these issues go away.

To do this, you can either start a new environment when starting julia:

```bash
pjabardo@i023080L:~/temp/test$ julia --project=.
(test) pkg> st
Status `~/temp/test/Project.toml` (empty project)

```

Or start Julia normally and activate e new environment:

```shell
pjabardo@i023080L:~/temp/test$ julia 
(v1.8) pkg> activate .
  Activating new project at `~/temp/test`

(test) pkg> st
Status `~/temp/test/Project.toml` (empty project)

```

Now you can add project specific packages. Notice that this will create a `Project.toml` and `Manifest.toml` files that contains the specific dependencies used by the project.

Paulo

---

<div class="post-metadata">

**Author:** ![Christopher\_Fisher](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/christopher_fisher/32/26132_2.png) [@Christopher\_Fisher](https://discourse.julialang.org/u/Christopher_Fisher)\
**Post date:** [January 2, 2023, 2:19pm UTC](https://discourse.julialang.org/t/package-version-conflicts/92047/5 "2023-01-02T14:19:57Z")

</div>

I agree 100% with Paulo. In my run files, I included a few lines to activate the project-specific environment:

```julia
# set working directory to directory of current file
cd(@ __DIR__ )
using Pkg
Pkg.activate("path_to_environment_file")

```

I also recommend putting compatibility bounds in your Project.toml file. For example

```julia
[compat]
some_package = "0.1.0, 0.2.0"

```

In Julia 1.8 and higher, you can type `] status` to see if there are new versions of packages and whether they are outside of your bounds. You can decide whether to increase your compat bounds for new package versions. Switching to this workflow completely eliminated reproducibility problems and compatibility conflicts for me.

In fact, I would say that the Julia’s package system is one of its most underrated features. Good luck doing the same thing with the same effort in R or Python.

---

<div class="post-metadata">

**Author:** ![erlebach](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/erlebach/32/12973_2.png) [@erlebach](https://discourse.julialang.org/u/erlebach)\
**Post date:** [January 2, 2023, 6:32pm UTC](https://discourse.julialang.org/t/package-version-conflicts/92047/6 "2023-01-02T18:32:57Z")

</div>

Thanks. To be clear, I have been using environments as you describe, so far without version constraints. In Python, I now use virtual environments and Poetry.

---

<div class="post-metadata">

**Author:** ![Christopher\_Fisher](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/christopher_fisher/32/26132_2.png) [@Christopher\_Fisher](https://discourse.julialang.org/u/Christopher_Fisher)\
**Post date:** [January 2, 2023, 7:36pm UTC](https://discourse.julialang.org/t/package-version-conflicts/92047/7 "2023-01-02T19:36:15Z")

</div>

In that case, I think your chances of encountering a conflict are low. CompatHelper seems to do a good job keeping packages updated and working together on the development side.

If you add compat bounds based on versions you know to work together, then you can guarantee compatibility and have the control to opt into updates, and revert back if necessary.

Poetry looks quite useful. Thanks for the lead!