<div>Lock files it's good idea. We are using simple script for this purpose.</div><div>When you want create release branch just type create release. And script do recursive walk and lock dependency current version in root rebar.config.</div><div>All another time moving head most usable for our development process.</div><br>пятница, 19 октября 2012 г., 15:10:52 UTC+4 пользователь José Valim написал:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I believe one of the issues that would need to be addressed first in rebar is the one of repeatability.<div><br><div>rebar does not ensure that developers in the same project are going to use the same snapshot of a dependency. This means developers can depend on the same git repository but different commits leading to the famous "the tests pass on my machine".</div>
<div><br><div><div>I am aware this could be fixed by the team enforcing a commit sha when declaring the dependency but many simply don't do it. Besides it puts the work on you to manage the commit shas. If you want to update the dependency, you need to remove the commit sha, update the repo, write the new commit sha.</div>
<div><br></div><div>This could be easily fixed by having a lock file per project with the commit shas of the dependencies. "rebar get-deps" should retrieve the shas in such lock, if one is available, or simply get the latest and write to the lock. A command like "rebar unlock-deps" could be available when developers want to update their dependencies, regardless of the current lock.</div>
<div><br></div><div>Also, regarding Joe's proposal, picking up a version from a git repository may be tricky. The best approach is to index git tags only, hoping the publisher won't modify an existing tag. If someone is depending on a branch though, it should not be considered a version or a part of .erl_packages. I believe it should still belong to the repo.</div>
<div><br></div><div><span style="font-size:13px"><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b>José Valim</b></span></div><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><div>
<span style="font-family:verdana,sans-serif;font-size:x-small"><a href="http://www.plataformatec.com.br/" style="color:rgb(42,93,176)" target="_blank">www.plataformatec.com.br</a></span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Skype: jv.ptec</span></div>
<div><span style="font-family:verdana,sans-serif;font-size:x-small">Founder and Lead Developer</span></div></span></div></span></div><br>
<br><br><div class="gmail_quote">On Fri, Oct 19, 2012 at 12:36 PM, Joe Armstrong <span dir="ltr"><<a href="javascript:" target="_blank" gdf-obfuscated-mailto="f8_ftr16FnsJ">erl...@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here is a programming exercise ...<br>
<br>
I think we can turn rebar into a package manager with 4 simple and one not so<br>
simple tweaks.<br>
<br>
This would turn rebar from being something that is very useful to something<br>
that is very very useful :-)<br>
<br>
<br>
(aside - I'm revising my Erlang book, and I'd like to describe<br>
how package management works, but there is no package manager<br>
which is a shame - so I got to thinking about package managers<br>
and wondered why still don't have a decent package manager.<br>
<br>
The one I've seen that I like a lot is npm (node package manager)<br>
so we could do worse than follow their design)<br>
<br>
So this is how I think rebar could become a package manager<br>
<br>
<br>
Tweak 1<br>
=======<br>
<br>
> rebar get-deps<br>
<br>
Fetches the dependencies in rebar.conf and stores them in<br>
the current directory, in a directory called deps.<br>
<br>
After a while you get dependencies scattered all over the place,<br>
I've seen many examples of this.<br>
<br>
This means that there is no central place to go and look if you<br>
want to find code.<br>
<br>
NPM sticks ALL dependencies under ${HOME}/.npm<br>
<br>
Suggestion:<br>
<br>
All dependencies should be stored in ${HOME}/.erl_packages<br>
<br>
(Aside - if we followed npm the directory structure would be<br>
something like)<br>
<br>
${HOME}/.erl_packages/cowboy/<wbr>6.2.1/src<br>
/ebin<br>
/5.2.3<br>
/stdlib/12.3.1<br>
/14.6.8<br>
<br>
etc. ie a package/Vsn/src ... structure<br>
<br>
<br>
Tweak 2<br>
=======<br>
<br>
move rebar.config to ${HOME}/.erl_packages/rebar.<wbr>config<br>
and add commands to automatically edit it<br>
<br>
> rebar add_package foo<br>
<br>
might add a line like<br>
{foo, ".*", "git://...."}<br>
<br>
to rebar.config<br>
<br>
The point here is to change the content of rebar.config with<br>
shell commands rather that editing it by hand<br>
<br>
Tweak 3<br>
=======<br>
fix rebar so it just downloads a particular version of a<br>
program and not all the .git stuff - most people will only<br>
want to use other peoples code, not hack it.<br>
<br>
Tweak 4<br>
=======<br>
<br>
Fix the erlang load paths to find all the dependencies<br>
<br>
I do this now. Put all my dependencies in<br>
${HOME}/nobackup/erlang_<wbr>imports/deps and put the following<br>
code in my .erlang startup file<br>
<br>
Home = os:getenv("HOME").<br>
Dir = Home ++ "/nobackup/erlang_imports/<wbr>deps",<br>
case file:list_dir(Dir) of<br>
{ok, L} -><br>
lists:foreach(fun(I) -><br>
Path = Dir ++ "/" ++ I ++ "/ebin",<br>
code:add_path(Path)<br>
end, L);<br>
_ -><br>
void<br>
end.<br>
<br>
Tweak 5<br>
=======<br>
This can't be done by rebar<br>
Make an index of all erlang apps on github that follow<br>
the erlang packaging structure<br>
<br>
Somebody has to write a program to do this.<br>
<br>
The package index should be at a well know URL<br>
<br>
> rebar get_index<br>
<br>
<br>
This should fetch the index from the well-know URL and store in<br>
${HOME}/.erl_packages<br>
<br>
<br>
> rebar search XXX<br>
<br>
would search the fetched index<br>
<br>
> rebar add XXXX<br>
<br>
would take the index entry add it to the config fill fetch the code<br>
and compile it<br>
<br>
Note the following:<br>
<br>
1) The trust model.<br>
<br>
We trust the supplier of a program not the program.<br>
<br>
So for example on github we might trust programs<br>
published by the user joearms (me) or erlang (the OTP release)<br>
but not by some_guy_ive_never_hear_of<br>
<br>
It would be quite easy to add a trust section to rebar.config<br>
<br>
{trust, ["git://joearms", git://erlang", ...]}<br>
<br>
2) There is no "publish" step<br>
<br>
We put our code on github (or somewhere) and hope that it gets indexed<br>
by the indexer.<br>
<br>
We might mail the indexer if it is published in an obscure place.<br>
<br>
Comments?<br>
<br>
Cheers<br>
<br>
/Joe<br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="javascript:" target="_blank" gdf-obfuscated-mailto="f8_ftr16FnsJ">erlang-q...@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</blockquote></div><br></div></div></div>
</blockquote>