# Sync'ing Julia packages between multiple machines

**URL:** <https://discourse.julialang.org/t/syncing-julia-packages-between-multiple-machines/101081>\
**Category:** General Usage\
**Created:** [July 2, 2023, 4:30pm UTC](https://discourse.julialang.org/t/syncing-julia-packages-between-multiple-machines/101081 "2023-07-02T16:30:03Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![ryofurue](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ryofurue/32/24531_2.png) [@ryofurue](https://discourse.julialang.org/u/ryofurue)\
**Post date:** [July 2, 2023, 4:30pm UTC](https://discourse.julialang.org/t/syncing-julia-packages-between-multiple-machines/101081/1 "2023-07-02T16:30:03Z")

</div>

Suppose you use multiple machines and personally manage your Julia environment. What do you do to sync packages between those machines?

I’m not a “developer” and I don’t need serious version control at all. I’m happy with always upgrading to the latest versions of the packages.

The simplest method I think of now is to write the output of `Pkg.status()` to a text file on one machine, send it to another machine (or share it via cloud drive), and read and parse it on the other machine to install the missing packages.

If all my machines were of the same architecture I could just rsync `~/.julia/` but would that work between Intel mac, M2 mac, and Linux?

---

<div class="post-metadata">

**Author:** ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)\
**Post date:** [July 2, 2023, 4:40pm UTC](https://discourse.julialang.org/t/syncing-julia-packages-between-multiple-machines/101081/2 "2023-07-02T16:40:35Z")

</div>

I suppose the problem here is that you do not have one Project, but multiple projects, so just keeping the `Manifest.toml` synced is not enough?

---

<div class="post-metadata">

**Author:** ![ryofurue](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ryofurue/32/24531_2.png) [@ryofurue](https://discourse.julialang.org/u/ryofurue)\
**Post date:** [July 2, 2023, 5:01pm UTC](https://discourse.julialang.org/t/syncing-julia-packages-between-multiple-machines/101081/3 "2023-07-02T17:01:36Z")

</div>

Thanks for your response, but

> I suppose the problem here is that you do not have one Project, but multiple projects, so just keeping the `Manifest.toml` synced is not enough?

I know very little about “Project” and I know _nothing_ about `Manifest.toml`.

With this in mind, can you elaborate on your advice?

I’ve just searched for `Manifest.toml` under `~/.julia/` and found a lot of them. Do you mean I sync all of them and do nothing more than that to sync packages?

---

<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:** [July 2, 2023, 5:11pm UTC](https://discourse.julialang.org/t/syncing-julia-packages-between-multiple-machines/101081/4 "2023-07-02T17:11:40Z")

</div>

The best approach in my opinion is to use a project specific environment which would have its own Project.toml file for compatibility bounds and optionally a shared Manifest.toml which would provide constraints on all dependencies (and dependencies of dependencies etc.). If you use the global version of those files in /.julia, you are likely to have divergences.

You can make project specific environments with the package management [system](https://pkgdocs.julialang.org/v1/environments/) or with PkgTemplates.jl (which is similar but for a full package). Using a private Github repo would be one way to synchronize across machines. I know you said you are not a developer, but those tools are good for your stated purpose and are not too complicated to learn with a bit of practice.

---

<div class="post-metadata">

**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:** [July 2, 2023, 6:21pm UTC](https://discourse.julialang.org/t/syncing-julia-packages-between-multiple-machines/101081/5 "2023-07-02T18:21:47Z")

</div>

To be more specific:

In one machine, you start Julia and do:

```julia
mkdir MyProject
cd MyProject
julia # start Julia

```

In Julia:

```julia
julia> activate . # activate the MyProject (current dir) project

julia> import Pkg; Pkg.add(["Plots", "DifferentialEquations"]) # your packages

```

This will create two files in the directory `MyProject`: `Project.toml` and `Manifest.toml`. The first contains the list of packages of you added to your project, the later the _exact_ version of every package installed in your environment. These two files is what you need.

When running your code/scripts, you do:

```julia
cd MyProject
julia --project script.jl 
#or
julia --project # to start a interactive julia section with the project activated

```

Then, copy those two files (or the complete directory) to your other computer. The first time you will then do:

```julia
cd MyProject
julia
# in Julia
julia> import Pkg; Pkg.instantiate()

```

This will install all the necessary packages with the exact versions listed in the `Manifest.toml` file.

You can then run your script exactly as in the original machine.

(as mentioned above, this directory can be associated to a github repository, in which case you can clone the repository in other machines, instead of “copying” the data, the main advantage being the version control, backup, easy of use for other people).

---

<div class="post-metadata">

**Author:** ![marius311](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/marius311/32/3953_2.png) [@marius311](https://discourse.julialang.org/u/marius311)\
**Post date:** [July 2, 2023, 9:05pm UTC](https://discourse.julialang.org/t/syncing-julia-packages-between-multiple-machines/101081/6 "2023-07-02T21:05:36Z")

</div>

> [@ryofurue](#):
>
> I know very little about “Project” and I know _nothing_ about `Manifest.toml`.

Project.toml is a file that stores the package names of installed packages for a given environment and Manifest.toml stores the package names _and_ also exact versions of packages. A pair of Project.toml/Manifest.toml uniquely and completely define an entire package environment and can be used to recreate it anywhere else.

If you’re working mainly in the global environment, these files are in somewhere like `~/.julia/environments/v1.9/`. So copy just those two from one machine to the other at the same location. Then on the new machine, open up Julia and run `pkg> instantiate`. Now all packages at the exact same versions are installed on the new machine.

---

<div class="post-metadata">

**Author:** ![ryofurue](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ryofurue/32/24531_2.png) [@ryofurue](https://discourse.julialang.org/u/ryofurue)\
**Post date:** [July 3, 2023, 9:05am UTC](https://discourse.julialang.org/t/syncing-julia-packages-between-multiple-machines/101081/7 "2023-07-03T09:05:16Z")

</div>

Thank you all for your kind help! I now understand (better) how a Project is managed. Because I’m so far happy with just one default “environment”, I’d probably go with

> `~/.julia/environments/v1.9/` . So copy just those two from one machine to the other at the same location. Then on the new machine, open up Julia and run `pkg> instantiate` . Now all packages at the exact same versions are installed on the new machine.

This is exactly a kind of method which I had suspected would already exist before I posted my initial question (and before starting to write my own script that would sync the packages using the `Pkg` package).

I’ll try to sync these files via github because I agree with

> Using a private Github repo would be one way to synchronize across machines. I know you said you are not a developer, but those tools are good for your stated purpose and are not too complicated to learn with a bit of practice.