# Multiple Versions of one Module in same Environment

**URL:** <https://discourse.julialang.org/t/multiple-versions-of-one-module-in-same-environment/15162>\
**Category:** General Usage\
**Created:** [September 19, 2018, 8:31am UTC](https://discourse.julialang.org/t/multiple-versions-of-one-module-in-same-environment/15162 "2018-09-19T08:31:35Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![maximilianpreisinger](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@maximilianpreisinger](https://discourse.julialang.org/u/maximilianpreisinger)\
**Post date:** [September 19, 2018, 8:31am UTC](https://discourse.julialang.org/t/multiple-versions-of-one-module-in-same-environment/15162/1 "2018-09-19T08:31:35Z")

</div>

Hello Guys,

this is both a question and a feature request.  
I am very happy with the new package manager and the environment solution, so that the dependency hell can be decreased. However I figured out a situation, where you can encounter a dependency issue.  
For example, when you use Module1 with the latest version, which requires Module2 in version 0.1, but your own program actually requires functions from Module2 in version 0.2, then you got a problem. You have to decide if you either install Module1 latest and Module2@0.1, or if you install just Module2@0.2 and uninstall Module1.

I read here: [Unsatisfiable requirements for package ForwardDiff - #8 by tkelman](https://discourse.julialang.org/t/unsatisfiable-requirements-for-package-forwarddiff/4922/8)  
that it is not possible to install different versions of one package, at least for julia 0.6. Did this maybe change with julia 1.0? If not, would it be possible to introduce such a feature in future julia versions?  
One could for example install the latest Module2 under the name `Module2`, and any other version of it under ´Module2\_0.1.0´. And then via metaprogramming make Module1 using Module2\_0.1.0.

How do you see this issue?

---

<div class="post-metadata">

**Author:** ![Nosferican](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nosferican/32/9275_2.png) [@Nosferican](https://discourse.julialang.org/u/Nosferican)\
**Post date:** [September 19, 2018, 8:42am UTC](https://discourse.julialang.org/t/multiple-versions-of-one-module-in-same-environment/15162/2 "2018-09-19T08:42:47Z")

</div>

No and it shouldn’t. You can have different versions installed, but each environment can use only one version.

---

<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:** [September 19, 2018, 8:44am UTC](https://discourse.julialang.org/t/multiple-versions-of-one-module-in-same-environment/15162/3 "2018-09-19T08:44:40Z")

</div>

> [@Pkg can't load packages present in Manifest.toml?](https://discourse.julialang.org/t/pkg-cant-load-packages-present-in-manifest-toml/13636/4):
>
> You can only have one version of a given package at a time. You can, however, have different packages with the same name in the overall dependency graph. It is intentional that you must explicitly declare your dependencies at the top level. These are connected facts since the top-level Colors could be totally unrelated to an indirect Colors dependency.

The workaround, as noted in that thread, is to fix one of the packages.

---

<div class="post-metadata">

**Author:** ![maximilianpreisinger](https://avatars.discourse-cdn.com/v4/letter/m/a3d4f5/32.png) [@maximilianpreisinger](https://discourse.julialang.org/u/maximilianpreisinger)\
**Post date:** [September 20, 2018, 12:25pm UTC](https://discourse.julialang.org/t/multiple-versions-of-one-module-in-same-environment/15162/4 "2018-09-20T12:25:17Z")

</div>

Ok I see. This actually makes sense when both packages are still maintained.  
I only see a problem, when one of the packages is not actively maintained any more. Then it will be hard to use it, because all the surrounding dependencies grow and grow, but the package itself still relies on old dependencies. But maybe that is the smaller problem, when a package isn’t maintained any more.