[erlang-questions] Erlang package manager

zxq9 zxq9@REDACTED
Tue Dec 16 14:52:15 CET 2014


On 2014年12月16日 火曜日 08:08:51 Fred Hebert wrote:
> On 12/16, Bruce Yinhe wrote:
> >    - What metadata information should an Erlang package include?
> >    - What functionality do you need in a package manager for Erlang in
> >    order to use it in production?
> >    - What other concerns do you have about an Erlang package management
> >    system?
> 
> I'd certainly like to see signing addressed by a would-be package manager.

With that in mind, I would like to see a signed repo (or optionally signed 
repo, with a selectable sensitivity) where deps/packages/whatever are curated 
to some degree instead of just being "go fetch $trash from $place, which 
hopefully still exists".

In this sense building a base of Erlang deps is not unlike managing a meta OS 
distribution, and the tasks of a full-blown build/dep/repo tool are not unlike 
the stack of services that underly ports/portage or cpan.

Separation of the "packaging" job from the "code scribbling" job is, in my 
opinion, a healthy thing. This has been my experience in packaging/managing 
Linux distros in the past, and I see more useful parallels in the curation 
model there than in the "grab $shit from $codesite", and felt the pain of not 
doing it right in Cabal in the past. In particular, the repo itself should be 
versioned collectively -- so you have an API promise within major versions 
within revisions of the same dep definition within the overall repo major 
release. So you can "write against OTP17R + E-Universe 3" and know that your 
stuff  will build without chasing down breakages every time someone types 
"rebase" in their upstream project tree. (Of course... this means either 
upstream *or* packagers will have to adhere to a reasonable versioning 
scheme... otoh, curation gives packagers a chance to interdict idiotic 
upstream versioning...)

This is how I've come to view the build/packaging/repo/dep problem after 
dealing with it in OSes and language environments -- I don't think a simple 
(or separate, greatly divergent, incompatible) tools for each individual 
aspect will solve the problem. This is probably a heretical view to many 
people (its OK, already wearing fireproof undies).



More information about the erlang-questions mailing list