Perfect, however, I see it's still experimental. I guess people just need to start using .ez files then so it's more used and tested. We should probably have rebar be able to read a rebar.config file within the ez file to determine dependencies, no? <div>
<br><div><br><div class="gmail_quote">On Tue, Oct 30, 2012 at 10:33 AM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Oct 30, 2012 at 6:31 PM, Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>> wrote:<br>
> On Tue, Oct 30, 2012 at 6:17 PM, Andrew Berman <<a href="mailto:rexxe98@gmail.com">rexxe98@gmail.com</a>> wrote:<br>
>> I come from the Java world and I'm sorta blown away that Erlang doesn't have<br>
>> something comparable to JAR files, which work just fine.<br>
><br>
> Well it does actually - but this is not stunning well documented.<br>
><br>
> In the manual page for code there is a section entited<br>
><br>
> LOADING OF CODE FROM ARCHIVE FILES<br>
<br>
</div>My mail got sent before I'd completed it ...<br>
<br>
programs like rebar use these features<br>
<span class="HOEnZb"><font color="#888888"><br>
/Joe<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
><br>
><br>
>> Everyone needs to<br>
>> agree on a standard for which to package the applications. JARs are just<br>
>> zips of class files with config files, so why not start there and just have<br>
>> a zip file with the BEAMs and priv directory with configs. Then we need erl<br>
>> to be able to read these zip files and use them as libraries without having<br>
>> to unzip them. I think we need to just start simple and then evolve over<br>
>> time if we need to.<br>
>><br>
>> --Andrew<br>
>><br>
>> On Tue, Oct 30, 2012 at 4:08 AM, Tim Watson <<a href="mailto:watson.timothy@gmail.com">watson.timothy@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>> On 30 Oct 2012, at 09:41, Ignas Vyšniauskas wrote:<br>
>>><br>
>>> > On 10/23/2012 09:46 AM, Joe Armstrong wrote:<br>
>>> >> The above link has an example command<br>
>>> >><br>
>>> >>>> git fetch-pack --include-tag -v git@github.com:hyperthunk/gitfoo.git<br>
>>> > refs/tags/lager-0.9.4<br>
>>> ><br>
>>> > Wouldn't --depth=1 make it even better? Do we need all of the history<br>
>>> > here?<br>
>>> ><br>
>>><br>
>>> Indeed we do not, though I've not tried that. Someone also mentioned to me<br>
>>> offline (a while ago) that they were concerned about using git as a backend<br>
>>> rather than adopting something that is not only distributed but actually has<br>
>>> mirrors in place, e.g., apt/yum or whatever. Stashing things using git<br>
>>> simply seemed like a *free* way to get started when I was first looking at<br>
>>> it.<br>
>>><br>
>>> So, I'm fairly sure we're not going to figure out a way to do this that<br>
>>> pleases everybody. And *even* if the package management and distribution<br>
>>> problem was neatly solved, there would be cases where you might actually<br>
>>> *want* source code dependencies instead. Another reason we looked at git was<br>
>>> because once you've built everything, if you're resolving dependencies from<br>
>>> a central location (like $HOME/repo or whatever) then you've got to deploy<br>
>>> them as a snapshot each time they're built and so on. This stuff actually<br>
>>> gets quite involved - using say maven, which is actually very good at<br>
>>> managing this, it can still make the development process over complicated at<br>
>>> times.<br>
>>><br>
>>> Take an example project: RabbitMQ. You're building multiple projects that<br>
>>> depend on each other, and the bug you're fixing involves making changes to<br>
>>> three different components, each of which lives in its own repository.<br>
>>> How're you going to figure out which projects need to be built if they're<br>
>>> all completely discrete by the time they go into the repository? Of course<br>
>>> its easy to solve dependencies with make and rebar will compile *including*<br>
>>> dependencies by default, which goes a long way to making this situation<br>
>>> workable in practise.<br>
>>><br>
>>> Of course what Joe is really talking about is the ability to install<br>
>>> *other people's work* for which you have absolutely no (or maybe just very<br>
>>> little) interest in the source code. I typically don't care how a particular<br>
>>> bit of cowboy or webmachine or whatever work, as long as it does I just<br>
>>> ignore it.<br>
>>><br>
>>> And this problem cannot be *that hard* to solve, because you know what -<br>
>>> stuff like rubygems/bundler is really damn useful, as it PyPI. I'm sure the<br>
>>> node thing is great, though I've never looked. Even OCaml Godi comes in<br>
>>> useful and despite the vitriol I hear about it, cabal+hackage is invaluable.<br>
>>> Point is, these things make it easy to get stuff done, thought they have<br>
>>> gaps, flaws and whatnot - they still add a lot of value.<br>
>>><br>
>>> Oh and BTW if someone does come up with a system to do this, then it<br>
>>> *should* just be packaged as a rebar plugin, as there's no need to change<br>
>>> rebar at all in order to override things like these.<br>
>>><br>
>>> Cheers,<br>
>>> Tim<br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<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>
>>><br>
>><br>
>><br>
>> _______________________________________________<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>
>><br>
</div></div></blockquote></div><br></div></div>