# Understanding dependencies and reproducibility

**URL:** <https://discourse.julialang.org/t/understanding-dependencies-and-reproducibility/70419>\
**Category:** General Usage\
**Tags:** reproducibility\
**Created:** [October 26, 2021, 5:41pm UTC](https://discourse.julialang.org/t/understanding-dependencies-and-reproducibility/70419 "2021-10-26T17:41:22Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![shiroghost](https://avatars.discourse-cdn.com/v4/letter/s/b9e5f3/32.png) [@shiroghost](https://discourse.julialang.org/u/shiroghost)\
**Post date:** [October 26, 2021, 5:41pm UTC](https://discourse.julialang.org/t/understanding-dependencies-and-reproducibility/70419/1 "2021-10-26T17:41:22Z")

</div>

Hi all,

I am trying to understand better reproducibility and the working of the Package manager.

Let’s say that I develop a Package “A”, that depends on some third party packages (example CUDA.jl). Now I develop a program, in an enviroment. I add both packages “A” (deloped by myself), and CUDA using Pkg.add(“…”).

My question, is What version of CUDA is being used in my enviroment? Is there a way to force, when adding a package, that this dependency is resolved in some predicted way?

Many thanks,

A.

---

<div class="post-metadata">

**Author:** ![StevenWhitaker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevenwhitaker/32/9749_2.png) [@StevenWhitaker](https://discourse.julialang.org/u/StevenWhitaker)\
**Post date:** [October 26, 2021, 7:48pm UTC](https://discourse.julialang.org/t/understanding-dependencies-and-reproducibility/70419/2 "2021-10-26T19:48:41Z")

</div>

When you `add` a package, the most up-to-date version that is compatible with other installed packages is installed. So what version of CUDA.jl you get depends on what you have in the `[compat]` section of A.jl’s Project file (this is true regardless of whether you yourself develop A.jl).

Maybe this section of Pkg.jl’s manual will be helpful to you: [6. Compatibility · Pkg.jl](https://pkgdocs.julialang.org/v1.6/compatibility/).

---

<div class="post-metadata">

**Author:** ![shiroghost](https://avatars.discourse-cdn.com/v4/letter/s/b9e5f3/32.png) [@shiroghost](https://discourse.julialang.org/u/shiroghost)\
**Post date:** [October 26, 2021, 8:00pm UTC](https://discourse.julialang.org/t/understanding-dependencies-and-reproducibility/70419/3 "2021-10-26T20:00:59Z")

</div>

Thank you very much.

Ok, so this par is clear.

Now, just to make sure if my understanding of reproducibility is clear. No matter what the [compat] section says, If my environment is in a git and someone clones this repo and activate it they will run exactly the versions of all packages as they are specified in the Manifest file. Is this correct?

Many thanks!

A.

---

<div class="post-metadata">

**Author:** ![StevenWhitaker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevenwhitaker/32/9749_2.png) [@StevenWhitaker](https://discourse.julialang.org/u/StevenWhitaker)\
**Post date:** [October 26, 2021, 8:04pm UTC](https://discourse.julialang.org/t/understanding-dependencies-and-reproducibility/70419/4 "2021-10-26T20:04:16Z")

</div>

Yes: [4. Working with Environments · Pkg.jl](https://pkgdocs.julialang.org/v1/environments/#Using-someone-else's-project)

---

<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 26, 2021, 8:30pm UTC](https://discourse.julialang.org/t/understanding-dependencies-and-reproducibility/70419/5 "2021-10-26T20:30:12Z")

</div>

> [@shiroghost](#):
>
> Now, just to make sure if my understanding of reproducibility is clear. No matter what the [compat] section says, If my environment is in a git and someone clones this repo and activate it they will run exactly the versions of all packages as they are specified in the Manifest file. Is this correct?

Yes - that is the purpose of `]instantiate`. It takes a `Manifest.toml` and instantiates it exactly as described. This is the preferred approach to reproducing e.g. versions for a paper or some analysis that you’ve run (and tested with known-good versions!).

You can also use `]pin --all` to pin all dependencies to their current versions, disallowing version updates for packages in that environment. This may not be desirable for a library, where you define version bounds for compatible versions - if they’re pinned, they will hold other packages back, as there can only ever be one version of a library installed.