<div dir="ltr">Is there any sort of centralized repository for this?<div><br></div><div>Coming from the Node.js world, we have npm (with all it's faults and flaws). Npm doesn't use git</div><div>for versioning. Git history can be rewritten, and anyone can remove (semver) release tags,</div><div>so it's kinda pointless.<br></div><div><br></div><div>Scenario:</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>I request extend/cowboy.git#0.9, the people at extend overwrite the 0.9 tag and then the next time</div><div>I'm pulling that repo, I'll get a different version of the library. This of course does not aid in</div><div>deterministic builds.</div></blockquote><div><br></div><div>On the other hand, by using npm, regardless of whether you store your code (github, bitbucket, locally),</div><div>you publish a release from your current computer and it basically uploads a tarball. Sure you can</div><div>keep track of release numbers using git tags too, but everyone can get any published version.</div><div><br></div><div>Fundamental to deterministic builds is not being able to *republish* under a version name. Which obligues</div><div>you to increment your semver with every fix, feature, and major overhaul.</div><div><br></div><div>So if there was something like an erlang package manager –epm?– (I've seen agner/agner but seems very</div><div>outdated), anyone could specify the module name and release version in rebar, and rebar would talk</div><div>to these service instead and get exactly what it needs, instead of relying on a variable data-source.</div><div><br></div><div>This approach has long helped the node community to collaborate and share modules more easily,</div><div>and in a community where every week there's a new build tool (grunt, gulp, broccoli, jake, and a billion more)</div><div>npm has remained a constant factor from the very early days.</div><div><br></div><div>In any case, I'd be interested in learning more of what's currently available for erlang to deal with this</div><div>issues, so any pointers are very much welcomed :)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 17, 2015 at 11:26 AM, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 03/17, Loïc Hoguin wrote:<br>
> I believe rebar3 has a way to lock dependencies into a specific commit for<br>
> the projects that depend on another's "master".<br>
<br>
</span>Yes. It's done automatically when compiling, building releases, or any<br>
other command that depends on compiled modules being there (an explicit<br>
`rebar3 lock' command can be run too).<br>
<br>
---<br>
<br>
Another answer that Joe might want is the possibility of using releases.<br>
Whether it's with systools, reltool, relx (possibly via <a href="http://erlang.mk" target="_blank">erlang.mk</a> or<br>
rebar3), releases allow you to ship an Erlang program with its minimal<br>
version of the Erlang VM, with the code pre-compiled.<br>
<br>
This at least removes the requirement that the user has Erlang or make<br>
installed, and makes it so Joe (or the release creator) used a similar<br>
runtime system to compile the application, or took specific steps to<br>
cross-compile.<br>
<br>
Releases also have the option to ship without stdlibs or the ERTS in<br>
case you want them to run on a target system with an existing copy of<br>
Erlang in there.<br>
<br>
If the code uses no NIFs, such portable releases are really the best way<br>
to go about distributing Erlang code.<br>
<br>
The big constraint is that you must write OTP applications for these to<br>
work, which I know Joe sometimes likes not to do (a supervisor bridge<br>
may help such cases: <a href="http://www.erlang.org/doc/man/supervisor_bridge.html" target="_blank">http://www.erlang.org/doc/man/supervisor_bridge.html</a><br>
<br>
Regards,<br>
Fred.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span style="font-family:arial">Leandro Ostera</span><div dir="ltr" style="font-family:arial"><div><br></div><div><font size="1"><a href="http://github.com/ostera" style="color:rgb(17,85,204)" target="_blank">Github</a> | <a href="http://linkedin.com/in/leostera" style="color:rgb(17,85,204)" target="_blank">LinkedIn</a> | <a href="http://facebook.com/leostera" style="color:rgb(17,85,204)" target="_blank">Facebook</a> | <a href="http://twitter.com/leostera" style="color:rgb(17,85,204)" target="_blank">@leostera</a></font></div></div></div></div></div></div></div></div>
</div>