# Elpe, the universal package installer
Elpe is a package installer using ideas from immutable Linux
distributions ([Nix](https://nixos.org),
[Silverblue](https://silverblue.fedoraproject.org)) and also from
conventional distributions (such as [Debian](https://debian.org) and
[Ubuntu](https://ubuntu.com)) 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](https://www.youtube.com/watch?v=0mCsluv5FXA), 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](https://github.com/stumpsyn/policies/blob/master/citizen_code_of_conduct.md).
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](https://wiki.debian.org/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.

Contact: mailto:contact@pijul.org
Expires: 2026-06-01T00:00:00z