[erlang-questions] Erlang package manager

[Tuncer Ayaz]

On Mon, Dec 22, 2014 at 7:18 PM, Judson Lester 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.

Yes, Nix solves a lot of common issues in elegant ways, and if we go
that route, I'd support it.

> On Mon Dec 22 2014 at 4:14:47 AM Tuncer Ayaz wrote:
> >
> > On Mon, Dec 22, 2014 at 12:36 PM, Loic Hoguin wrote:
> > > Hello,
> > >
> > > Adding something I believe nobody mentioned yet (if I missed it,
> > > sorry).
> > >
> > > The way things are now there are many companies or larger
> > > projects who have a fork of some of the projects they use,
> > > because they need a specific set of patches on top of them
> > > (sometimes these can easily be contributed back; but sometimes
> > > they are plain hacks).
> > >
> > > The package manager should be able to handle this, perhaps by
> > > allowing some package information to be overriden to allow
> > > changing the source location.
> > >
> > > Another solution could be to allow applying a set of patch
> > > files.
> > >
> > > None of this would apply to binary-only packages though, of
> > > course.
> >
> > That's what 'pinning' is for, and AFAIR it has been mentioned by
> > others, but it's good to point it out again for clarity :).
> >
> > For example, with opam you can do the following:
> >
> > # fetch source and pin as preferred source
> > $ opam source public_pkg --pin
> > $ cd public_pkg
> > # apply modifications
> >
> > # add pkg that only exists locally
> > $ cd private_pkg
> > $ opam pin add private_pkg .
> >
> > Now, anytime you run 'opam install' or 'opam upgrade', opam will
> > use the local dir as the source.
> >
> > Gentoo's portage calls this an 'overlay'.
> >
> > You may also want a similar feature like Debian's pinning, but
> > that's a different thing, and I'm not sure if it's needed.