[erlang-questions] Erlang package manager

[Gleb Peregud]

I am currently working on a proof of concept for Nix packages in Erlang.
Here are the assumptions of mine:
- maintenance of Nix packages should be automated
- tarballs with packages should come from a single source
- be willing to sacrifice backward compatibility to be able to do automatic
maintenance
- Nix packages should be usable both for deployment and development
- provide reproducible (but not necessary hermetic) builds of Erlang
packages and all their both Erlang and non-Erlang dependencies

This leads to the following approach:
- use Hex.pm as source of packages' tarballs and metadata
- exclusively use Rebar3 as a build tool, but not as a package management
tool
- import latest versions of each package on Hex.pm and their deps'
transitive closures
- the import needs to be mostly automated and should be able to run in "a
cron" (e.g. on Travis)

Here's my first stab onto it, focusing purely on Nix part, without working
on the scripts/tooling yet:
https://github.com/NixOS/nixpkgs/pull/11614

If there are Nix-ers here, please take a look.and comment.
If you are curious about details, feel free to ask questions.

Best regards,
Gleb Peregud

On Sun, Jan 4, 2015 at 12:01 PM, Tuncer Ayaz <tuncer.ayaz@REDACTED> wrote:

> On Sat, Jan 3, 2015 at 6:16 PM, Tuncer Ayaz wrote:
> > On Sat, Jan 3, 2015 at 3:54 PM, Bjorn-Egil Dahlberg wrote:
> > > Hi everyone!
>
> [...]
>
> > > 3. Protocols first. I saw someone mentioning this already and it
> > > made me so happy. Protocols first is perhaps a misnomer but it is
> > > important anyway. We have several languages that runs ontop of
> > > beam or Erlang. Elixir has its own package manger Hex (client) and
> > > Hexweb (server) and I think it is a good thing if we use
> > > compatible protocols. Http and restful protocols is all the rage
> > > and I don't any reason to sidestep that. My vision here is a
> > > common protocol bus and the client can query any server for Erlang
> > > applications, i.e. Hex can query an Erlang Application provider
> > > for updates and install them. I think this only affect us (Erlang)
> > > by pressuring us to formalize our rest protocols / api .. but that
> > > is a good thing.
> >
> > As long as we're not held back by limitations of existing protocols,
> > and are free to improve/extend, sure, it's a good approach.
>
> Thinking about, it appears what you're actually suggesting is a smart
> http protocol which would disallow easy mirroring. If that's the case,
> then it's a bad idea.
>
> I've explained this in my initial response to Bruce, but I'll try to
> summarize the benefits of a simple files+dirs structure served via
> http/ftp/_whatever_:
>
> * Like mirrors for CTAN, anyone who wishes to host a mirror can do so
> easily alongside CTAN, *nix distros, etc., without the need for a
> special CGI script or extra http daemon. This greatly increases the
> reliability and availability by avoiding the need for a centrally
> managed and to-be-accessed smart host that has to be paid for and
> administered. No matter how professional and CDN'ed something is, it
> will eventually go down for a period. Using a conventionally
> mirror'able structure avoids "is foo.erlang.org down?" questions and
> broken builds, as users will by convention use mirrors instead of a
> central location. For this to be a non-issue, we'd have to have van
> Jacobson's content-centric networking (or one of the derivatives) in
> addition to more reliable global network links.
>
> * It's easy to set up public or private mirrors.
>
> * In case of problems, it gives you the option of restoring or
> checking the integrity of files by making use several independent,
> trusted mirrors that hadn't been updated to the problematic state yet.
>
> That said, it's perfectly fine to have one or more registries where
> stuff is published to and mirrored from.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151211/688ca6aa/attachment.htm>