[erlang-questions] Including other peoples code in my code in a future proof way

[Leandro Ostera]

Is there any sort of centralized repository for this?

Coming from the Node.js world, we have npm (with all it's faults and
flaws). Npm doesn't use git
for versioning. Git history can be rewritten, and anyone can remove
(semver) release tags,
so it's kinda pointless.

Scenario:

I request extend/cowboy.git#0.9, the people at extend overwrite the 0.9 tag
and then the next time
I'm pulling that repo, I'll get a different version of the library. This of
course does not aid in
deterministic builds.


On the other hand, by using npm, regardless of whether you store your code
(github, bitbucket, locally),
you publish a release from your current computer and it basically uploads a
tarball. Sure you can
keep track of release numbers using git tags too, but everyone can get any
published version.

Fundamental to deterministic builds is not being able to *republish* under
a version name. Which obligues
you to increment your semver with every fix, feature, and major overhaul.

So if there was something like an erlang package manager –epm?– (I've seen
agner/agner but seems very
outdated), anyone could specify the module name and release version in
rebar, and rebar would talk
to these service instead and get exactly what it needs, instead of relying
on a variable data-source.

This approach has long helped the node community to collaborate and share
modules more easily,
and in a community where every week there's a new build tool (grunt, gulp,
broccoli, jake, and a billion more)
npm has remained a constant factor from the very early days.

In any case, I'd be interested in learning more of what's currently
available for erlang to deal with this
issues, so any pointers are very much welcomed :)

On Tue, Mar 17, 2015 at 11:26 AM, Fred Hebert <mononcqc@REDACTED> wrote:

> On 03/17, Loïc Hoguin wrote:
> > I believe rebar3 has a way to lock dependencies into a specific commit
> for
> > the projects that depend on another's "master".
>
> Yes. It's done automatically when compiling, building releases, or any
> other command that depends on compiled modules being there (an explicit
> `rebar3 lock' command can be run too).
>
> ---
>
> Another answer that Joe might want is the possibility of using releases.
> Whether it's with systools, reltool, relx (possibly via erlang.mk or
> rebar3), releases allow you to ship an Erlang program with its minimal
> version of the Erlang VM, with the code pre-compiled.
>
> This at least removes the requirement that the user has Erlang or make
> installed, and makes it so Joe (or the release creator) used a similar
> runtime system to compile the application, or took specific steps to
> cross-compile.
>
> Releases also have the option to ship without stdlibs or the ERTS in
> case you want them to run on a target system with an existing copy of
> Erlang in there.
>
> If the code uses no NIFs, such portable releases are really the best way
> to go about distributing Erlang code.
>
> The big constraint is that you must write OTP applications for these to
> work, which I know Joe sometimes likes not to do (a supervisor bridge
> may help such cases: http://www.erlang.org/doc/man/supervisor_bridge.html
>
> Regards,
> Fred.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>



-- 
Leandro Ostera

Github <http://github.com/ostera> | LinkedIn
<http://linkedin.com/in/leostera> | Facebook <http://facebook.com/leostera>
 | @leostera <http://twitter.com/leostera>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150317/ad33e9d0/attachment.htm>