eigenpy is available in nixpkgs, so defining another version of the package based on git is only a matter of overriding the source specification from there.
This override filter some files/dirs among the git tracked sources, to avoid rebuilding when only README / CHANGELOG / other metadata files change.
This package can then be built with nix build. The result will be available in the nix store, with a result symlink to it. Build logs can be streamed to the current stdout with the -L flag.
A flake
Since the overridden package is provided in a flake, the git repository become usable directly from nix, including:
a way for other nix flakes to reference and use any given version of this package, eg:
github:stack-of-tasks/eigenpy/9fa85b547c9ef0ba3bcd5297b4050f15769c61b3: from a commit hash
github:stack-of-tasks/eigenpy/9fa85b5: from a short rev
github:stack-of-tasks/eigenpy/nix: from a branch
github:stack-of-tasks/eigenpy/vX.Y.Z: from a tag (once this will be merged a tag including this will be available)
github:stack-of-tasks/eigenpy: from the repo (once this will be merged into master, which is the default branch)
/path/to/eigenpy: from a local clone absolute path
.: from a local clone relative path
(nothing): this is a short hand for .
a way to build those: nix build $REF
a way to run eigenpy directly:
nix run $REF will start a python interpreter with eigenpy installed.
nix develop $REF will start a shell with all eigenpy dependencies available. At this point, eg. classical cmake -B build -S . && cmake --build build will work directly.
with echo "use flake" > .envrc && direnv allow and nix-direnv, this shell will automatically activate itself on entering into the directory, and deactivate itself on leaving.
CI jobs
Linux and MacOS jobs on Github Action will run nix build, allowing to detect early:
if anything new in the repo would break the nix packaging
if any update from a dependency in upstream nixpkgs would break eigenpy
A binary cache
The CI jobs will push the built packages to https://gepetto.cachix.org, so users won't have to build a version which was already built by CI.
And vice-versa, users will be able to push to that cache, so that those CI jobs can be no-op.
Hi,
This add some features related to Nix, including:
An override
eigenpy is available in nixpkgs, so defining another version of the package based on git is only a matter of overriding the source specification from there.
This override filter some files/dirs among the git tracked sources, to avoid rebuilding when only README / CHANGELOG / other metadata files change.
This package can then be built with
nix build. The result will be available in the nix store, with aresultsymlink to it. Build logs can be streamed to the current stdout with the-Lflag.A flake
Since the overridden package is provided in a flake, the git repository become usable directly from nix, including:
github:stack-of-tasks/eigenpy/9fa85b547c9ef0ba3bcd5297b4050f15769c61b3: from a commit hashgithub:stack-of-tasks/eigenpy/9fa85b5: from a short revgithub:stack-of-tasks/eigenpy/nix: from a branchgithub:stack-of-tasks/eigenpy/vX.Y.Z: from a tag (once this will be merged a tag including this will be available)github:stack-of-tasks/eigenpy: from the repo (once this will be merged into master, which is the default branch)/path/to/eigenpy: from a local clone absolute path.: from a local clone relative path.nix build $REFnix run $REFwill start a python interpreter with eigenpy installed.nix run github:stack-of-tasks/eigenpy/nix -- -c "import eigenpy; print(eigenpy.__version__)"=>3.8.2nix develop $REFwill start a shell with all eigenpy dependencies available. At this point, eg. classicalcmake -B build -S . && cmake --build buildwill work directly.echo "use flake" > .envrc && direnv allowand nix-direnv, this shell will automatically activate itself on entering into the directory, and deactivate itself on leaving.CI jobs
Linux and MacOS jobs on Github Action will run
nix build, allowing to detect early:A binary cache
The CI jobs will push the built packages to https://gepetto.cachix.org, so users won't have to build a version which was already built by CI. And vice-versa, users will be able to push to that cache, so that those CI jobs can be no-op.