Turning rebar into a package manager - Erlang Programming

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Turning rebar into a package manager
Received-SPF: pass (google.com: domain of erlang-questions-boun...@erlang.org designates 192.121.151.104 as permitted sender) client-ip=192.121.151.104;
MIME-Version: 1.0
In-Reply-To: <CAANBt-rKKYRyWiAgOCU=vAkvqRWzGMoBQyi8U43B2UjWpQw...@mail.gmail.com>
References: <CAANBt-om0_w2PqWjdwdNOdCewOx8-6zRB2AT=Jru1O1OVJJ...@mail.gmail.com>
 <50814888.3050...@ferd.ca>
 <CAANBt-qvztTwyUNQ1K3x6VNRi1Yw+wt4gesH39+HQbswiwt...@mail.gmail.com>
 <508FA0E1.2080...@gmail.com> <BDE323DE-AC12-415E-8B27-E3A0EA90D...@gmail.com>
 <CAEVpa77iZDhKqZZBNnEenGjkvZK_8VUsdiqn8iDB2=pNQcR...@mail.gmail.com>
 <CAANBt-pLNRrUDwn0xxVSOT3bctMxiP3MZdYW-KZyVoV3JBz...@mail.gmail.com>
 <CAANBt-rKKYRyWiAgOCU=vAkvqRWzGMoBQyi8U43B2UjWpQw...@mail.gmail.com>
From: Andrew Berman <rexx...@gmail.com>
Date: Tue, 30 Oct 2012 10:58:12 -0700
Message-ID: <CAEVpa779tQYW8MtkuWZPb-Js9HMe6BJCCybbWbjWUed3HnU...@mail.gmail.com>
To: Joe Armstrong <erl...@gmail.com>
Cc: Erlang <erlang-questi...@erlang.org>
Subject: Re: [erlang-questions] Turning rebar into a package manager
Precedence: list
Content-Type: multipart/mixed; boundary="===============0942417045874402730=="
Errors-To: erlang-questions-boun...@erlang.org
Sender: erlang-questions-boun...@erlang.org

--===============0942417045874402730==
Content-Type: multipart/alternative; boundary=047d7b339003ced5db04cd4a8896

--047d7b339003ced5db04cd4a8896
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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?


On Tue, Oct 30, 2012 at 10:33 AM, Joe Armstrong <erl...@gmail.com> wrote:

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

--047d7b339003ced5db04cd4a8896
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Perfect, however, I see it&#39;s still experimental. =C2=A0I guess people j=
ust need to start using .ez files then so it&#39;s more used and tested. =
=C2=A0We should probably have rebar be able to read a rebar.config file wit=
hin the ez file to determine dependencies, no? =C2=A0<div>

<br><div><br><div class=3D"gmail_quote">On Tue, Oct 30, 2012 at 10:33 AM, J=
oe Armstrong <span dir=3D"ltr">&lt;<a href=3D"mailto:erl...@gmail.com" targ=
et=3D"_blank">erl...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

<div class=3D"im">On Tue, Oct 30, 2012 at 6:31 PM, Joe Armstrong &lt;<a hre=
f=3D"mailto:erl...@gmail.com">erl...@gmail.com</a>&gt; wrote:<br>
&gt; On Tue, Oct 30, 2012 at 6:17 PM, Andrew Berman &lt;<a href=3D"mailto:r=
exx...@gmail.com">rexx...@gmail.com</a>&gt; wrote:<br>
&gt;&gt; I come from the Java world and I&#39;m sorta blown away that Erlan=
g doesn&#39;t have<br>
&gt;&gt; something comparable to JAR files, which work just fine.<br>
&gt;<br>
&gt; Well it does actually - but this is not stunning well documented.<br>
&gt;<br>
&gt; In the manual page for code there is a section entited<br>
&gt;<br>
&gt; LOADING OF CODE FROM ARCHIVE FILES<br>
<br>
</div>My mail got sent before I&#39;d completed it ...<br>
<br>
programs like rebar use these features<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
/Joe<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
&gt;<br>
&gt;<br>
&gt;&gt; =C2=A0Everyone needs to<br>
&gt;&gt; agree on a standard for which to package the applications. =C2=A0J=
ARs are just<br>
&gt;&gt; zips of class files with config files, so why not start there and =
just have<br>
&gt;&gt; a zip file with the BEAMs and priv directory with configs. =C2=A0T=
hen we need erl<br>
&gt;&gt; to be able to read these zip files and use them as libraries witho=
ut having<br>
&gt;&gt; to unzip them. =C2=A0I think we need to just start simple and then=
 evolve over<br>
&gt;&gt; time if we need to.<br>
&gt;&gt;<br>
&gt;&gt; --Andrew<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Oct 30, 2012 at 4:08 AM, Tim Watson &lt;<a href=3D"mailto:=
watson.timo...@gmail.com">watson.timo...@gmail.com</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 30 Oct 2012, at 09:41, Ignas Vy=C5=A1niauskas wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &gt; On 10/23/2012 09:46 AM, Joe Armstrong wrote:<br>
&gt;&gt;&gt; &gt;&gt; The above link has an example command<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt;&gt;&gt; git fetch-pack --include-tag -v g...@github.co=
m:hyperthunk/gitfoo.git<br>
&gt;&gt;&gt; &gt; refs/tags/lager-0.9.4<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; Wouldn&#39;t --depth=3D1 make it even better? Do we need =
all of the history<br>
&gt;&gt;&gt; &gt; here?<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Indeed we do not, though I&#39;ve not tried that. Someone also=
 mentioned to me<br>
&gt;&gt;&gt; offline (a while ago) that they were concerned about using git=
 as a backend<br>
&gt;&gt;&gt; rather than adopting something that is not only distributed bu=
t actually has<br>
&gt;&gt;&gt; mirrors in place, e.g., apt/yum or whatever. =C2=A0Stashing th=
ings using git<br>
&gt;&gt;&gt; simply seemed like a *free* way to get started when I was firs=
t looking at<br>
&gt;&gt;&gt; it.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; So, I&#39;m fairly sure we&#39;re not going to figure out a wa=
y to do this that<br>
&gt;&gt;&gt; pleases everybody. And *even* if the package management and di=
stribution<br>
&gt;&gt;&gt; problem was neatly solved, there would be cases where you migh=
t actually<br>
&gt;&gt;&gt; *want* source code dependencies instead. Another reason we loo=
ked at git was<br>
&gt;&gt;&gt; because once you&#39;ve built everything, if you&#39;re resolv=
ing dependencies from<br>
&gt;&gt;&gt; a central location (like $HOME/repo or whatever) then you&#39;=
ve got to deploy<br>
&gt;&gt;&gt; them as a snapshot each time they&#39;re built and so on. This=
 stuff actually<br>
&gt;&gt;&gt; gets quite involved - using say maven, which is actually very =
good at<br>
&gt;&gt;&gt; managing this, it can still make the development process over =
complicated at<br>
&gt;&gt;&gt; times.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Take an example project: RabbitMQ. You&#39;re building multipl=
e projects that<br>
&gt;&gt;&gt; depend on each other, and the bug you&#39;re fixing involves m=
aking changes to<br>
&gt;&gt;&gt; three different components, each of which lives in its own rep=
ository.<br>
&gt;&gt;&gt; How&#39;re you going to figure out which projects need to be b=
uilt if they&#39;re<br>
&gt;&gt;&gt; all completely discrete by the time they go into the repositor=
y? Of course<br>
&gt;&gt;&gt; its easy to solve dependencies with make and rebar will compil=
e *including*<br>
&gt;&gt;&gt; dependencies by default, which goes a long way to making this =
situation<br>
&gt;&gt;&gt; workable in practise.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Of course what Joe is really talking about is the ability to i=
nstall<br>
&gt;&gt;&gt; *other people&#39;s work* for which you have absolutely no (or=
 maybe just very<br>
&gt;&gt;&gt; little) interest in the source code. I typically don&#39;t car=
e how a particular<br>
&gt;&gt;&gt; bit of cowboy or webmachine or whatever work, as long as it do=
es I just<br>
&gt;&gt;&gt; ignore it.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; And this problem cannot be *that hard* to solve, because you k=
now what -<br>
&gt;&gt;&gt; stuff like rubygems/bundler is really damn useful, as it PyPI.=
 I&#39;m sure the<br>
&gt;&gt;&gt; node thing is great, though I&#39;ve never looked. Even OCaml =
Godi comes in<br>
&gt;&gt;&gt; useful and despite the vitriol I hear about it, cabal+hackage =
is invaluable.<br>
&gt;&gt;&gt; Point is, these things make it easy to get stuff done, thought=
 they have<br>
&gt;&gt;&gt; gaps, flaws and whatnot - they still add a lot of value.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Oh and BTW if someone does come up with a system to do this, t=
hen it<br>
&gt;&gt;&gt; *should* just be packaged as a rebar plugin, as there&#39;s no=
 need to change<br>
&gt;&gt;&gt; rebar at all in order to override things like these.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Cheers,<br>
&gt;&gt;&gt; Tim<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; erlang-questions mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:erlang-questi...@erlang.org">erlang-question=
s...@erlang.org</a><br>
&gt;&gt;&gt; <a href=3D"http://erlang.org/mailman/listinfo/erlang-questions=
" target=3D"_blank">http://erlang.org/mailman/listinfo/erlang-questions</a>=
<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; erlang-questions mailing list<br>
&gt;&gt; <a href=3D"mailto:erlang-questi...@erlang.org">erlang-questions@er=
lang.org</a><br>
&gt;&gt; <a href=3D"http://erlang.org/mailman/listinfo/erlang-questions" ta=
rget=3D"_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
&gt;&gt;<br>
</div></div></blockquote></div><br></div></div>

--047d7b339003ced5db04cd4a8896--

--===============0942417045874402730==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

--===============0942417045874402730==--
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
