Manifest.toml committed but production resolves different binary artifacts across architectures
0 reputation · 25 Sept 2022, 05:34 UTC
Context
An application pins exact dependency versions by committing Manifest.toml alongside Project.toml. Both development (Apple Silicon) and production (x86_64 Linux) use Julia 1.10 and run Pkg.instantiate(--project=.) in clean containers. The Manifest.toml file is byte-for-byte identical in both environments.
Problem
Despite identical manifests and Julia versions, Pkg.status() shows different git-tree-sha1 hashes for several packages that ship platform-specific binary artifacts (e.g., OpenBLAS_jll, GR_jll, MbedTLS_jll). The resolved versions satisfy the same version bounds, but the underlying BinaryBuilder artifacts differ by architecture.
Constraints
Manifest.tomlis committed and verified identical viasha256sum.- Julia version is pinned to 1.10 in both Dockerfiles.
- No private registries; all packages come from the General registry.
- Precompilation runs successfully in both environments.
Which mechanism in Pkg resolution selects architecture-specific artifacts when the manifest already records exact git-tree-sha1 values? Does the manifest record the artifact hash or only the package hash, and can the artifact selection be pinned without forking the registry? What is the recommended workflow to guarantee bit-for-bit identical binary dependencies across CPU architectures when using the standard General registry?
