Let me announce a new version of Pylightnix, the Nix-like data storage library in pure Python.
Since most of the readers know what Nix is, I’d like to highlight the differences between it and Pylightnix:
- The scale. Pylightnix is a library to be used in applications, the software package management is not among its primary goals.
- Pylightnix uses Python programs where Nix uses Nix expressions.
- In Pylightnix, we require users to explicitly specify the managed part of a derivation. We expect it to be a JSON-friendly Python object (an arbitrary structure made of dicts,lists,prims,but for example not tuples). Only these objects are involved in the dependency analysis.
- Pylightnix supports non-deterministic “builds” resulting in multiple concurrent realizations to co-exist in storage. We allow users to filter them by calling a special type of callbacks called Matchers. We hope this feature will be useful, for example, in machine learning or other scientific applications.
- In Pylightnix, objects are not tied to the location of the storage in the filesystem.
- We support “promised” artifacts declared in the expression. The interpreter checks if the promises are fulfilled and may throw an error earlier if it finds they are not.
Pylightnix remains quite compact (cloc returned 2450). It is written in a non-idiomatic procedural Python, requires no Python dependencies (but does optionally depend on
atool), employs mypy and hypothesis for testing. The recent changes include:
- Support for
with current_registrycontexts, allowing to write a more Python-looking spaghetti code.
- Implemented “spack”/“sunpack” which roughly resemble nix-copy-closure into zip-archives.
mklenstool for dot-style accessing the artifacts.
(The project was previously discussed here Pylightnix - A lightweight nix-like DSL in Python for ML)