[erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]]

[Garrett Smith]

On Tue, Feb 18, 2014 at 7:13 AM, Leo Liu <sdl.web@REDACTED> wrote:
> On 2014-02-18 20:21 +0800, Aaron France wrote:
>> Then you mustn't use the vast, vast majority of Erlang projects.
>
> Good projects come with good documentation because they are meant to be
> (re-)used. There are loads of rubbish erlang code out there. Maybe the
> community could outlaw them?

I nominate you as the law keeper in this Wild West :)

But if we wanted to think of this as an open ecosystem without this
sort of control, I'd point the list to the outstanding Arch User
Repository:

https://aur.archlinux.org/

Here anyone can provide an Arch package, which is purely source.
Consumers can use this to (easily) build packages (many of which pull
from github or other source repos but not all) that can then be
installed by a privileged user (this is just the way system packages
work, if you're nervous, with good cause, use a container). Packages
get votes, so you can see very easily how popular something is. If a
package gets enough votes it might get picked up by a core package
maintainer and land in the standard package ecosystem (mirrors).

I think what's being kicked around here (Mark?) is a similar type of
index, which crawls github (or part of it) to compile packages that
have some well known metadata file. Maybe this could be a PDF :)

Though I'd vote for an Erlang property file as per file:consult/1.

Maybe this all exists today and I'm just too heads down in other
things to have noticed. But if a single index with a voting scheme
emerged as a de facto standard (i.e. actually *used* by people) we'd
have an important missing piece in this ecosystem. At least if I'm
understanding the problem correctly.

This doesn't address the package artifact type, but I'm going on the
assumption this would fall under the domain of Erlang releases.
Naturally whatever artifacts are generated should work both as system
software (i.e. installed by privileged users) and be consumable as
dependencies by other Erlang applications. As I understand things,
this is all part of the existing release scheme and is supported in
varying degrees by current tools.

Garrett