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.<br><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Judson</div><br><div class="gmail_quote">On Mon Dec 22 2014 at 4:14:47 AM Tuncer Ayaz <<a href="mailto:tuncer.ayaz@gmail.com">tuncer.ayaz@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Dec 22, 2014 at 12:36 PM, Loic Hoguin wrote:<br>
> Hello,<br>
><br>
> Adding something I believe nobody mentioned yet (if I missed it,<br>
> sorry).<br>
><br>
> The way things are now there are many companies or larger projects<br>
> who have a fork of some of the projects they use, because they need<br>
> a specific set of patches on top of them (sometimes these can easily<br>
> be contributed back; but sometimes they are plain hacks).<br>
><br>
> The package manager should be able to handle this, perhaps by<br>
> allowing some package information to be overriden to allow changing<br>
> the source location.<br>
><br>
> Another solution could be to allow applying a set of patch files.<br>
><br>
> None of this would apply to binary-only packages though, of course.<br>
<br>
That's what 'pinning' is for, and AFAIR it has been mentioned by<br>
others, but it's good to point it out again for clarity :).<br>
<br>
For example, with opam you can do the following:<br>
<br>
# fetch source and pin as preferred source<br>
$ opam source public_pkg --pin<br>
$ cd public_pkg<br>
# apply modifications<br>
<br>
# add pkg that only exists locally<br>
$ cd private_pkg<br>
$ opam pin add private_pkg .<br>
<br>
Now, anytime you run 'opam install' or 'opam upgrade', opam will use<br>
the local dir as the source.<br>
<br>
Gentoo's portage calls this an 'overlay'.<br>
<br>
You may also want a similar feature like Debian's pinning, but that's<br>
a different thing, and I'm not sure if it's needed.<br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</blockquote></div>