[erlang-questions] Turning rebar into a package manager

[Andrew Berman]

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.  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.timothy@REDACTED>wrote:

>
> On 30 Oct 2012, at 09:41, Ignas Vyšniauskas wrote:
>
> > On 10/23/2012 09:46 AM, Joe Armstrong wrote:
> >> The above link has an example command
> >>
> >>>> git fetch-pack --include-tag -v git@REDACTED:hyperthunk/gitfoo.git
> > refs/tags/lager-0.9.4
> >
> > Wouldn't --depth=1 make it even better? Do we need all of the history
> 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 git
> 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 that
> 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 dependencies
> 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 situation
> 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 just ignore it.
>
> And this problem cannot be *that hard* to solve, because you know what -
> 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-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121030/9b7909d9/attachment.htm>