Julia environment reproducibility across disparate operating systems

Direct Answer

No, Julia does not support a single platform-agnostic Manifest.toml for binary dependencies. The manifest records exact versions of jll packages (binary artifacts) that differ by OS and architecture. A manifest generated on Linux will fail or pull incompatible binaries when instantiated on macOS or Windows.

Recommended multi-OS strategy: Commit only Project.toml to version control. Let each developer and CI runner generate its own Manifest.toml locally via Pkg.instantiate(). For applications that require reproducible binary versions per platform, commit per-platform manifests using a naming convention (e.g., Manifest.toml.linux, Manifest.toml.macos) and restore the correct one in CI.

Why Manifest.toml Is Not Portable

• Manifest.toml locks the full dependency tree, including jll packages that wrap binary artifacts (OpenBLAS_jll, GR_jll, HDF5_jll, etc.).
• Each jll package publishes distinct builds per platform (Linux x86_64, macOS arm64, Windows x86_64, etc.) with different UUIDs, versions, and hashes.
• When Pkg.instantiate() reads a manifest, it expects the recorded binary artifacts to exist for the current platform. Cross-platform mismatches cause resolution errors or silent selection of wrong binaries.
• Julia 1.9+ improved cross-platform resolution logic but did not change the file format: the manifest remains a per-platform snapshot.

Recommended Workflows

Libraries (Packages)

1. Commit Project.toml only.
2. Do not commit Manifest.toml.
3. Consumers run Pkg.instantiate() on their platform to resolve a valid manifest.

Applications (Deployable Projects)

1. Commit Project.toml.
2. In CI, run Pkg.instantiate() on each target OS (Linux, macOS, Windows) to generate a platform-specific Manifest.toml.
3. Optionally save each as Manifest.toml.linux, Manifest.toml.macos, Manifest.toml.windows for auditability.
4. At deploy/runtime, copy the correct platform manifest to Manifest.toml before instantiating.

What Breaks If You Share One Manifest

• Pkg.instantiate() fails with "artifact not found" or checksum errors for any jll dependency.
• Transitive dependencies often pull in binary artifacts even if your direct deps are pure Julia.
• Manual editing or merging of manifests is unsupported and corrupts the lockfile.

Verification You Can Run Today

# On Linux
julia --project -e 'using Pkg; Pkg.add("Zlib_jll"); Pkg.instantiate()'
cp Manifest.toml Manifest.toml.linux

# On macOS (or in a macOS CI runner)
julia --project -e 'using Pkg; Pkg.instantiate()'
cp Manifest.toml Manifest.toml.macos

# Diff the two manifests
diff -u Manifest.toml.linux Manifest.toml.macos

You will see different UUID/version/hash entries for Zlib_jll and its dependencies.

One Diagnostic Detail That Changes the Recommendation

Does your project have any direct or transitive dependency on a jll package (binary artifact)? Run Pkg.status() after instantiate on each OS and check for packages ending in _jll. If the answer is "no" (pure-Julia tree), a single committed Manifest.toml can be shared—but this is fragile because a future dependency update may introduce a binary artifact without notice.