[erlang-questions] Erlang package manager

[Joe Armstrong]

Using nix package seems to open a lot of interesting questions.

For example: what is the "scope" of an Erlang package manager/build system?

I see a hierarchy of needs:

   1) Package/distribute/build "pure" Erlang applications

      This seems at first sight to be easy(ish) but is complicated
      by the fact that Erlang has changed with time. Program with new
      language features (say maps in R17+) will not work with R < 17

   2) Package apps with NIFS

      Now we have additional dependencies upon OS, versions of
compiler, libraries

   3) Package apps with things being interfaced with.

      For example a particular Erlang library with NIFs and all, might provide
      an interface to MySQL.

      Do we want the package to install and build MySQL as well?

   4) Package an entire OS with Erlang and MySQL

   5) Package a cloud :-)

   We could in principle start anywhere in this heirarchy. For example
to do 1) we'd need to know the SHA1 checksum of the tree describing
the Erlang used to test the package, then compile the application into
a tree and compute the checksum of the tree. Then store the tree as blob
and make it available.

The Nix package manager is the only system I'm aware of that seems to
address problems like this - an entire system is described by a single
SHA1 checksum (in principle) and is thus cacheable - given that we can
represent a blob by a hash, and (recursively) a tree by a hash we can
describe the state of an entire system by a single hash - at least
that's the theory. This is *fantastic* if works in practise - I know the theory
but does it really work?

This means that, for example, a build of a NIF with a specific version of Erlang
with a specific version of gcc and so on reduces to a tree with a specific hash.

For common systems we can retrieve a binary copy given the hash, and
for uncommon
combinations we'll have to rebuild from the sources.

Has anybody made any Nix build scripts for Erlang?


On Mon, Dec 22, 2014 at 9:38 PM, Tristan Sloughter <t@REDACTED> wrote:
> I tried to do this with Nix a while ago and failed miserably -- requires
> a lot of hacky bash scripting. If anyone can get it to work I'd be
> interested in using it.

Interesting - I read the papers and was impressed - I downloaded NiX
on my MacBook  and the first command in the tutorial I was following
failed.

Can anybody point me to a good tutorial other than the manual page
and various academic papers?

Cheers

/Joe



> --
>   Tristan Sloughter
>   t@REDACTED
>
> On Mon, Dec 22, 2014, at 02:31 PM, Gleb Peregud wrote:
>> On Mon, Dec 22, 2014 at 7:18 PM, Judson Lester <nyarly@REDACTED> wrote:
>> > I'm not the only one, but I'd like to raise another voice for Nix. The world
>> > has far too many package managers specific to either a virtual machine or an
>> > OS distribution, and it's kind of a nightmare.
>> >
>> > My understanding is that Nix Package Manager (as opposed to the closely
>> > related NixOS) fulfills all or almost all the requirements that people are
>> > talking about here, as well as allowing unprivileged users to install
>> > software, establishing different installation contexts on the same host
>> > (i.e. different versions of dependencies for different applications), and
>> > completely reproducible installs.
>> >
>> > But most attractive: it wouldn't be "the Erlang Package Manager" - it'd be
>> > "the Erlang application of Nix," which has at least three benefits: Erlang
>> > benefits from improvements to Nix, the Erlang community has a stronger basis
>> > for input on Nix, and anyone who's used Nix before but not Erlang has the
>> > barrier to trying Erlang lowered slightly.
>>
>> I second this. Nix does solve most of these problems (if not all) in a
>> very principled, well-defined and consistent way, including:
>> - hermetic, verifiable and reproducible builds
>> - patch sets
>> - interoperation with other languages
>> - really fast
>> - transparent binary distribution of artifacts (obviously with
>> fallback to building from source)
>> - extensive caching of build artifacts
>> - private and public repositories
>> - unprivileged installation
>> - multiple version of the same package can coexist and won't conflict
>> - one command deployment (with all dependencies) to normal OS, to
>> Docker or to a cloud
>> - centralized configuration management
>> - developer-friendly
>> - etc. etc. etc.
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions