+ # 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.