[erlang-questions] Turning rebar into a package manager
Tue Oct 30 18:33:35 CET 2012
On Tue, Oct 30, 2012 at 6:31 PM, Joe Armstrong <> wrote:
> On Tue, Oct 30, 2012 at 6:17 PM, Andrew Berman <> 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
>> 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.
>> On Tue, Oct 30, 2012 at 4:08 AM, Tim Watson <>
>>> 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 :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
>>> 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
>>> 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.
>>> erlang-questions mailing list
>> erlang-questions mailing list
More information about the erlang-questions