# How to use Manifests for a clean environment for reproducibility **URL:** \ **Category:** General Usage\ **Tags:** reproducibility\ **Created:** [October 14, 2021, 8:01am UTC](https://discourse.julialang.org/t/how-to-use-manifests-for-a-clean-environment-for-reproducibility/69755 "2021-10-14T08:01:11Z")\ **Posts on this page:** 7\ **Page:** 1

**Author:** ![ptoche](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ptoche/32/23554_2.png) [@ptoche](https://discourse.julialang.org/u/ptoche)\ **Post date:** [October 14, 2021, 8:01am UTC](https://discourse.julialang.org/t/how-to-use-manifests-for-a-clean-environment-for-reproducibility/69755/1 "2021-10-14T08:01:11Z")

> [@Things that are easier in Julia than Python/R etc](https://discourse.julialang.org/t/things-that-are-easier-in-julia-than-python-r-etc/69403/57): > > To be clear on this, a manifest file (i.e. `Manifest.toml` ) is not something you _write_ but is automatically created by the package manager Sloppy use of language on my part. My understanding is that the `Manifest.toml` file is the file you want to keep for reproducibility, as it lists all the packages used, while the `Project.toml` file is where you specify your idiosyncratic version needs. The `Manifest.toml` file is automatically generated, while the `Project.toml` file can be tweaked by the user. I’ll make sure to clearly distinguish manifest and project in future discussions! Veering off topic now. I must admit that I’m not sure how you would use the `Manifest.toml` file to set up a clean environment for reproducibility, since the system overwrites it. Do you copy the content of the `Manifest.toml` into `Project.toml` or something? ---

**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 14, 2021, 8:19am UTC](https://discourse.julialang.org/t/how-to-use-manifests-for-a-clean-environment-for-reproducibility/69755/2 "2021-10-14T08:19:37Z")

> [@ptoche](#): > > Veering off topic now. I must admit that I’m not sure how you would use the `Manifest.toml` file to set up a clean environment for reproducibility, since the system overwrites it. Do you copy the content of the `Manifest.toml` into `Project.toml` or something? The normal thing to do for reproducibility is to commit both `Project.toml` and `Manifest.toml` to version control and make sure that you run with this environment activated, e.g. by starting a script file with ```julia using Pkg Pkg.activate(@ __DIR__ ) Pkg.instantiate() ``` Obviously you shouldn’t update packages or similar in this environment after you have prepared it, but if you do, your version control will show that and let you undo it. For reproducibility you also want to make sure that you only depend on registered packages or other stuff within the same repository, i.e. no developed or added local paths outside of your repository. If you’re really serious about reproducibility you will also tweak the load path to exclude the default environment. ---

**Author:** ![sijo](https://avatars.discourse-cdn.com/v4/letter/s/da6949/32.png) [@sijo](https://discourse.julialang.org/u/sijo)\ **Post date:** [October 14, 2021, 8:45am UTC](https://discourse.julialang.org/t/how-to-use-manifests-for-a-clean-environment-for-reproducibility/69755/3 "2021-10-14T08:45:11Z")

> [@Things that are easier in Julia than Python/R etc](https://discourse.julialang.org/t/things-that-are-easier-in-julia-than-python-r-etc/69403/50): > > I ask because in R and Python, I occasionally discover I’m using old or obsolete packages, update them, and that’s that. In Julia, what happens is as you update one package, a bunch of other packages are downgraded. I love the standardized package management in Julia and find it rather robust, but I’ve had a similar experience with the version management: packages are often held back to old versions or even downgraded. This seems to happen much more frequently than in other ecosystems and I’d like to know why! Maybe it’s because Julia’s ecosystem is relatively immature and moving faster. Maybe developers are more casual with making new major (backward incompatible) releases: Suppose A just released version 0.13. You have installed B 1.5 that supports A 0.13. If later you install C that hasn’t been updated and only support A 0.12, it will downgrade both A and B. If A is fast moving, this can happen a lot. Another possibility is that we see more composition and reuse in Julia’s ecosystem, so packages have more dependencies on other packages by third-party developers, with different release schedules… This composition is great in some ways but also has costs… Maybe together with fast moving packages it can explain some of the difficulties with dependency resolution? ---

**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 14, 2021, 10:08am UTC](https://discourse.julialang.org/t/how-to-use-manifests-for-a-clean-environment-for-reproducibility/69755/4 "2021-10-14T10:08:53Z")

> [@sijo](#): > > packages are often held back to old versions or even downgraded. This seems to happen much more frequently than in other ecosystems and I’d like to know why! I think there are many reasons. Some that come to mind right away: Core: - Julia takes package compatibility and semantic versioning quite seriously. - For multiple dispatch and composability to work well it’s not really feasible to have disjoint dependencies, so the environment has to resolve to a single set of package versions to use. User side: - It’s common to cram too many packages into the default environment instead of using separate environments for different tasks or `activate --temp` for throwaway tests of packages. Packaging side: - Package authors are sometimes slow to add compatibility with new breaking versions of their dependencies. - (Variation) Compat is updated on master but no release is made so the compat update does not become available to the package ecosystem. - Compat with the new version is added but the old version is immediately dropped, even if the breaking change wasn’t actually affecting you. ---

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\ **Post date:** [October 14, 2021, 11:57am UTC](https://discourse.julialang.org/t/how-to-use-manifests-for-a-clean-environment-for-reproducibility/69755/5 "2021-10-14T11:57:39Z")

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\ **Post date:** [October 14, 2021, 3:36pm UTC](https://discourse.julialang.org/t/how-to-use-manifests-for-a-clean-environment-for-reproducibility/69755/6 "2021-10-14T15:36:31Z")

> [@GunnarFarneback](#): > > The normal thing to do for reproducibility is to commit both `Project.toml` and `Manifest.toml` to version control and make sure that you run with this environment activated, e.g. by starting a script file with > > ```julia > using Pkg > Pkg.activate(@ __DIR__ ) > Pkg.instantiate() > > ``` If you’re a little paranoid about packages updating, you can additionally `]pin --all` that environment. This stops Pkg from updating a dependency. ---

**Author:** ![ptoche](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ptoche/32/23554_2.png) [@ptoche](https://discourse.julialang.org/u/ptoche)\ **Post date:** [October 15, 2021, 6:10am UTC](https://discourse.julialang.org/t/how-to-use-manifests-for-a-clean-environment-for-reproducibility/69755/7 "2021-10-15T06:10:58Z")

Great, thank you! 😀