[erlang-questions] Erlang package manager
Wed Dec 17 10:14:26 CET 2014
On 2014年12月17日 水曜日 10:49:11 Loïc Hoguin wrote:
> On 12/17/2014 02:18 AM, Tristan Sloughter wrote:
> > * No global install
> > It just causes headaches. Sandboxes are much more fun to play in without
> > all the kids in the neighborhood crowding in and someone ending up
> > leaving a poop in it.
> I think this is a very important point. I like deps not because I enjoy
> compiling everything, but because they are local to the project and I
> can have different projects use different dep versions without having to
> worry that the wrong version gets picked up.
> I am not even sure how -pa or ERL_LIBS work when you have both app-1 and
> app-2 in your lib directory. Which one does it choose? Will it choose
> the right version when I want to start a shell for experimenting? I have
> not seen anything that allows me to choose what version to run outside
> of making a release/upgrade.
On this point, something that combines the best features of portage and mock
would be ideal as far as build/release goes -- especially as a foundation upon
which to script automated build/release of several concurrently maintained
major versions of a product (its almost as if people forgot this situation
exists...). Build environment isolation is of paramount importance, always.
That said, flexible definition of dependencies is necessary, and to have that
you have to make version numbers mean something (hence semver, or something
like it). You don't have to force developers to version their stuff, but you do
have to declare Maj.Min.Rev within the curated dep repo so that versions can
indicate where API promises are being upheld or broken. There is no practical
future for a tool that just "grabs the latest version of everything".
Especially not in Erland, the kingdom of super-duper legacy support software
Internal/external easy repo declaration (one of the best features of the RPM
createrepo and signature system), mirroring, etc. is a must-have for serious
use and broad adoption inside and outside of industry. It makes things flexible
and not dependent on whatever The Blessed Repo winds up being (like if it gets
screwy, or your network is down, or your boss has a serious NIH affliction, or
someone is allergic to open source, or whatever).
Taking yet another page from portage, the build system shouldn't hiccup when
building *your* project using deps that are fully from-source, fully binary,
arbitrary mix (based on availability) or whatever.
The repo building tool should default to building as much of both a source and
binary repo as it can, but wait to complain about anything until it completes
(whether success or failure, give a full report). It should optionally put
erldoc pages up and a package summary page in the repo root the way rpm and
deb repo tools do. In our case with all Erlang->Erlang development
dependencies adding full erldoc output for each package that has it is trivial
to add as a feature (and way more useful from a developers perspective, since
everything in the repo is effectively a "foo-dev" package for us, this not
being an OS repo).
More information about the erlang-questions