Reproducible Aliens: Keeping the Native Store Project-Local #8
sanko
started this conversation in
Show and tell
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
If you've ever installed a CPAN distribution on two different machines and been surprised when the C extension links against different versions of
libz, you've hit the classic "shared store" problem. Every CPAN module on the system shares one global xrepo store (~/.xmake/packages/); one install, upgrade, or accidentalxrepo cleancan silently change what a downstream Alien sees.Alien::Xreposolves this with installdir isolation: a project-local package store that never touches the global one. This article shows how to pin your native dependencies to a directory, cache them in CI, and transfer them offline.The default: the global store
By default, every call to
$repo->install(...)writes to the shared per-user store:That's convenient — multiple Perl modules share one
libpng. But it means a backgroundxrepo cleanor an unrelatedinstallwith different flags can change what your code sees.The fix: project-local isolation
Pass
root =>to the constructor, orinstalldir =>to any store-touching method, and the operation is confined to that directory:You can also isolate per-call, which is useful when the rest of your code uses the default store:
The
installdiroption applies toinstall,fetch,scan,uninstall,download, and every other method that touches the package store.What about the cache?
Downloading and building from source is slow. A project-local
installdirisolates where the installed files go, but the downloaded sources still live in the global cache by default.To isolate the cache too, pass
cachedir =>:This is especially handy in CI: the first run builds from source and caches; subsequent runs find everything already cached and return instantly.
What lives in the store?
The
scanmethod lists every package under a given store:This is also useful for verification — in a CI pipeline, after running
install, you canscanthe store and assert the expected package is present:Offline transfer with
download/import_pkg/exportOn machines without internet access (air-gapped CI runners, corporate build servers), you need a way to move the store around.
Alien::Xrepoprovides three methods for this:1. Download source archives
Fetch the source tarballs/7z archives to a local directory without building:
2. Export a built package
After building on a connected machine, export the package as a single archive:
3. Import on the target machine
On the air-gapped machine, import from the archive:
The three steps form a complete offline workflow: build once on a connected machine, export, transfer the archive, import on the target. No internet, no compilers, no retries.
CI integration
A concrete CI pattern — build and cache a project-local store:
On cache hit, the
installcalls resolve instantly (everything is already in the directory). On cache miss, they build from source and populate the cache.The dist builder integration
The dist builder (used internally to build this distribution's own
share/directory) uses the samerootmechanism to install all of xmake's own dependencies into the distribution'sshare/directory at build time. When a user runs./Build,Alien::Xrepo::Baseautomatically creates an isolated store underblib/shareso that the built distribution is fully self-contained.This is the same
root/installdirmechanism described above, just applied at distribution-build time rather than at user-install time. The principle is the same: isolate the store, and nothing leaks in or out.Summary
root => $storeinstalldir => $storecachedir => $storedownload/export/import_pkgAlien::Xrepo's store isolation turns a shared, mutable resource into a pinned, reproducible one; exactly what you need when a CI run or a CPAN release depends on a specific version of a native library.
All reactions