The Nest
Explore
0
README.md

Elpe, the universal package installer

Elpe is a package installer using ideas from immutable Linux distributions (Nix, Silverblue) and also from conventional distributions (such as Debian and Ubuntu) to create:

  • Ephemeral shells in which packages from conventional distributions are temporarily installed.

  • Isolated build environments, with the aim of being reproducible.

  • In the future, a different installer for Debian, Ubuntu and other Linux distributions.

We chose different sides of the trade-offs faced by NixOS, Silverblue or Docker:

  • Bootstrapping: Elpe does not aim at bootstrapping an entire system, and explicitly prefer packages from existing Linux distributions, possibly mixing-and-matching multiple versions and even multiple distributions. While bootstrapping (which NixOS does very well) is fun and elegant, it also requires massive resources to guarantee proper security and maintenance, especially on the lower-level parts of the system.

  • Description language: Elpe aims at describing an entire build process or system configuration using deterministic, reproducible code. The way Elpe achieves this is somewhere between Nix and Docker, since base distribution packages (packages from Ubuntu and Debian) are compiled using mostly unmodified upstream build systems, saving a lot of effort to make them strictly reproducible. However, your code is compiled in strict isolation, with only those packages in scope.

Security

This project is currently experimental and should not be used in production. However, improved security is one of our main focuses of this project. While day-to-day security is always a cat-and-mouse game, we believe a few improvements in the overall processes can help:

  • Defining builds as code running in isolation in a container gives an explicit picture of a full process. Elpe shares this property with Nix and Docker.

  • Reproducibility is an important part of security, even though it is far from the entire story. In particular, Elpe packages form a Merkle tree of their dependencies, making it easy and fast to check not only that a build recipe hasn't changed (like Nix), but also that an output (the binary package) hasn't changed (like Ubuntu).

  • Looking after the security of an entire package repository is extremely hard. By outsourcing this task to conventional distributions, we aim at making it possible to rely on an external auditing providers. Elpe shares this property with Docker, but unlike Docker, Elpe doesn't sacrifice the high reproducibility given by Nix.

  • Separation between your code and your distribution's code: the Elpe language provides a function to download Ubuntu packages. However, that function is designed to make it hard to modify anything from the distribution. This allows to structure security audits in a clearer way, since your code and build process (the part that only you can audit) is hygienically separated from the distribution's code and build process.

Language design

Which software engineer doesn't dream of inventing the perfect language? In Elpe, we acknowledge that doing that right is hard. We've picked the only language we know that:

  • Has an existing user base, industrial users, documentation and a sound static type system. We've tried early prototypes in Haskell, OCaml, Rust, Scala, TypeScript and Luau. Go was considered but the type system is less of a safety net, making it less "playful" than we wanted for a build system.

  • Makes brain teasers unappealing. This is a fun feature of Nix, but makes scaling harder and tends to please the wrong egos (this is just a build system, after all). Haskell or TypeScript would have been a lot of fun for different reasons. While learning Haskell is a great way to improve your programming, this isn't the purpose of a build system. Also, TypeScript's type checker can run Doom, which makes it too easy to express types that are too complicated for a build system.

  • Extremely fast compilation, which rules out Rust, Haskell and Scala.

  • Bytecode compilation or an existing virtual machine embedding. Both OCaml and Luau could work at this point.

  • However, while both are capable of structural types (not all build recipes have the exact same type) and late bindings (which we absolutely want for "quick hacks", which Nix calls "overrides), only OCaml also has nominal types, which are going to be extremely helpful to implement strict typing of configuration options.

Ready for scientific publications

Most scientific publications that involve code, in particular from machine learning, tend to give instructions in terms of Ubuntu packages. Elpe makes it easy to run them without having to translate instructions.

Contributing

Following the Debian manifesto as well as the goals of the Rust project, we intend the Elpe community to be inclusive and open. To that effect, we will enforce the Citizen Code of Conduct.

If you are interested in helping, here is the current areas that need help:

  • Fetchers. How do we import a package from a tarball given by a URL? From Git?

  • Interfaces with language package managers, in particular those requiring network access: of particular interest are Rust and OCaml, since they would allow us to bootstrap Elpe.

  • Creating a better documentation tool. While there isn't much more than a basic build system at the moment, creating documentation processes that can scale to a larger system is a key area. If you think you can build something at least as good as the ArchLinux Wiki (really high bar), please send patches.

  • Error handling. Currently, the system is made of a frontend (in OCaml) and a backend (in Rust) exchanging over gRPC. While this gives good modularity and a network-ready protocol with an explicit specification, it also means that errors have lots of edge cases and do not always translate well between languages.

  • Using Elpe to create a reproducible bootable ISO from Ubuntu packages. This is the first step towards building a full installer.

  • A Debconf interface. If you already know Debconf, or are interested in learning it, please reach out!

What about the project's name?

Elpe is the English back-transliteration of the Franglaise pronunciation of the English word «Help» (Franglaises quotes intended), chosen as a symbol of transcental solidarity and a tribute to our universal duty of always elping each other out.