[erlang-questions] Erlang package manager

[zxq9]

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 
cycles.

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).

Blah blah.

-Craig