pmeunier / elpe
Skip to content {/} code [~] changes [>] discussions [*] jobs<br>main Change Fork Rename Delete
Fork channel<br>Create a new channel as a copy of main .<br>New channel name Cancel Fork<br>Rename channel<br>Rename main to:<br>New name Cancel Rename<br>Delete channel<br>Delete main ? This cannot be undone.<br>Cancel Delete
mode name<br>drwxr-xr-x .well-known/<br>drwxr-xr-x darwinvm/<br>drwxr-xr-x elfedit/<br>drwxr-xr-x elpe/<br>drwxr-xr-x elpe-sched/<br>drwxr-xr-x eval-vm/<br>drwxr-xr-x examples/<br>drwxr-xr-x machoedit/<br>drwxr-xr-x mccs/<br>drwxr-xr-x reapi/<br>drwxr-xr-x scripts/<br>drwxr-xr-x src/<br>-rw-r--r-- .gitignore<br>-rw-r--r-- .ignore<br>-rw-r--r-- COPYING<br>-rw-r--r-- Cargo.lock<br>-rw-r--r-- Cargo.nix<br>-rw-r--r-- Cargo.toml<br>-rw-r--r-- README.md<br>-rw-r--r-- build.ml<br>-rw-r--r-- build.rs<br>-rw-r--r-- config.toml<br>-rw-r--r-- default.nix<br>-rw-r--r-- design.org<br>-rw-r--r-- flake.nix<br>-rw-r--r-- rustfmt.toml<br>-rw-r--r-- shell-nightly.nix<br>-rw-r--r-- shell.nix
README<br>Elpe, the universal package installer
Elpe is a package installer using ideas from immutable Linux<br>distributions (Nix,<br>Silverblue) and also from<br>conventional distributions (such as Debian and<br>Ubuntu) to create:
Ephemeral shells in which packages from conventional distributions<br>are temporarily installed.
Isolated build environments, with the aim of being reproducible.
In the future, a different installer for Debian, Ubuntu and other<br>Linux distributions.
We chose different sides of the trade-offs faced by NixOS, Silverblue<br>or Docker:
Bootstrapping: Elpe does not aim at bootstrapping an entire system,<br>and explicitly prefer packages from existing Linux distributions,<br>possibly mixing-and-matching multiple versions and even multiple<br>distributions. While bootstrapping (which NixOS does very well) is<br>fun and elegant, it also requires massive resources to guarantee<br>proper security and maintenance, especially on the lower-level parts<br>of the system.
Description language: Elpe aims at describing an entire build<br>process or system configuration using deterministic, reproducible<br>code. The way Elpe achieves this is somewhere between Nix and<br>Docker, since base distribution packages (packages from Ubuntu and<br>Debian) are compiled using mostly unmodified upstream build systems,<br>saving a lot of effort to make them strictly reproducible. However,<br>your code is compiled in strict isolation, with only those packages<br>in scope.
Security
This project is currently experimental and should not be used in<br>production. However, improved security is one of our main focuses of<br>this project. While day-to-day security is always a cat-and-mouse<br>game, we believe a few improvements in the overall processes can help:
Defining builds as code running in isolation in a container gives an<br>explicit picture of a full process. Elpe shares this property with<br>Nix and Docker.
Reproducibility is an important part of security, even though it is<br>far from the entire story. In particular, Elpe packages form a<br>Merkle tree of their dependencies, making it easy and fast to check<br>not only that a build recipe hasn’t changed (like Nix), but also<br>that an output (the binary package) hasn’t changed (like Ubuntu).
Looking after the security of an entire package repository is<br>extremely hard. By outsourcing this task to conventional<br>distributions, we aim at making it possible to rely on an external<br>auditing providers. Elpe shares this property with Docker, but<br>unlike Docker, Elpe doesn’t sacrifice the high reproducibility given<br>by Nix.
Separation between your code and your distribution’s code: the Elpe<br>language provides a function to download Ubuntu packages. However,<br>that function is designed to make it hard to modify anything from<br>the distribution. This allows to structure security audits in a<br>clearer way, since your code and build process (the part that only<br>you can audit) is hygienically separated from the distribution’s<br>code and build process.
Language design
Which software engineer doesn’t dream of inventing the perfect<br>language? In Elpe, we acknowledge that doing that right is hard. We’ve<br>picked the only language we know that:
Has an existing user base, industrial users, documentation and a<br>sound static type system. We’ve tried early prototypes in Haskell,<br>OCaml, Rust, Scala, TypeScript and Luau. Go was considered but the<br>type system is less of a safety net, making it less “playful” than<br>we wanted for a build system.
Makes brain teasers unappealing. This is a fun feature of Nix, but<br>makes scaling harder and tends to please the wrong egos (this is<br>just a build system, after all). Haskell or TypeScript would have<br>been a lot of fun for different reasons. While learning Haskell is a<br>great way to improve your programming, this isn’t the purpose of a<br>build system. Also, TypeScript’s type checker can run<br>Doom, which makes it<br>too easy to express types that are too complicated for a build<br>system.
Extremely fast compilation, which rules out Rust, Haskell and<br>Scala.
Bytecode compilation or an existing virtual machine embedding. Both<br>OCaml and Luau could...