<div dir="ltr">I am currently working on a proof of concept for Nix packages in Erlang. Here are the assumptions of mine:<div>- maintenance of Nix packages should be automated</div><div>- tarballs with packages should come from a single source</div><div>- be willing to sacrifice backward compatibility to be able to do automatic maintenance </div><div>- Nix packages should be usable both for deployment and development</div><div>- provide reproducible (but not necessary hermetic) builds of Erlang packages and all their both Erlang and non-Erlang dependencies</div><div><br></div><div>This leads to the following approach:</div><div>- use Hex.pm as source of packages' tarballs and metadata</div><div>- exclusively use Rebar3 as a build tool, but not as a package management tool</div><div>- import latest versions of each package on Hex.pm and their deps' transitive closures</div><div>- the import needs to be mostly automated and should be able to run in "a cron" (e.g. on Travis)</div><div><br></div><div>Here's my first stab onto it, focusing purely on Nix part, without working on the scripts/tooling yet:</div><div><a href="https://github.com/NixOS/nixpkgs/pull/11614">https://github.com/NixOS/nixpkgs/pull/11614</a><br></div><div><br></div><div>If there are Nix-ers here, please take a look.and comment.</div><div>If you are curious about details, feel free to ask questions.<br></div><div><br></div><div>Best regards,</div><div>Gleb Peregud</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 4, 2015 at 12:01 PM, Tuncer Ayaz <span dir="ltr"><<a href="mailto:tuncer.ayaz@gmail.com" target="_blank">tuncer.ayaz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, Jan 3, 2015 at 6:16 PM, Tuncer Ayaz wrote:<br>
> On Sat, Jan 3, 2015 at 3:54 PM, Bjorn-Egil Dahlberg wrote:<br>
> > Hi everyone!<br>
<br>
</span>[...]<br>
<span class=""><br>
> > 3. Protocols first. I saw someone mentioning this already and it<br>
> > made me so happy. Protocols first is perhaps a misnomer but it is<br>
> > important anyway. We have several languages that runs ontop of<br>
> > beam or Erlang. Elixir has its own package manger Hex (client) and<br>
> > Hexweb (server) and I think it is a good thing if we use<br>
> > compatible protocols. Http and restful protocols is all the rage<br>
> > and I don't any reason to sidestep that. My vision here is a<br>
> > common protocol bus and the client can query any server for Erlang<br>
> > applications, i.e. Hex can query an Erlang Application provider<br>
> > for updates and install them. I think this only affect us (Erlang)<br>
> > by pressuring us to formalize our rest protocols / api .. but that<br>
> > is a good thing.<br>
><br>
> As long as we're not held back by limitations of existing protocols,<br>
> and are free to improve/extend, sure, it's a good approach.<br>
<br>
</span>Thinking about, it appears what you're actually suggesting is a smart<br>
http protocol which would disallow easy mirroring. If that's the case,<br>
then it's a bad idea.<br>
<br>
I've explained this in my initial response to Bruce, but I'll try to<br>
summarize the benefits of a simple files+dirs structure served via<br>
http/ftp/_whatever_:<br>
<br>
* Like mirrors for CTAN, anyone who wishes to host a mirror can do so<br>
easily alongside CTAN, *nix distros, etc., without the need for a<br>
special CGI script or extra http daemon. This greatly increases the<br>
reliability and availability by avoiding the need for a centrally<br>
managed and to-be-accessed smart host that has to be paid for and<br>
administered. No matter how professional and CDN'ed something is, it<br>
will eventually go down for a period. Using a conventionally<br>
mirror'able structure avoids "is <a href="http://foo.erlang.org" rel="noreferrer" target="_blank">foo.erlang.org</a> down?" questions and<br>
broken builds, as users will by convention use mirrors instead of a<br>
central location. For this to be a non-issue, we'd have to have van<br>
Jacobson's content-centric networking (or one of the derivatives) in<br>
addition to more reliable global network links.<br>
<br>
* It's easy to set up public or private mirrors.<br>
<br>
* In case of problems, it gives you the option of restoring or<br>
checking the integrity of files by making use several independent,<br>
trusted mirrors that hadn't been updated to the problematic state yet.<br>
<br>
That said, it's perfectly fine to have one or more registries where<br>
stuff is published to and mirrored from.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>