[erlang-questions] Turning rebar into a package manager

Loïc Hoguin essen@REDACTED
Tue Oct 30 19:07:22 CET 2012


What I don't understand is what you would use these for? It's useful for 
tools like rebar because it's more a script with dependencies (all 
packaged in one file) than a full system, but it doesn't make sense for 
a full system which is generally done using releases (and these bundle 
the erl executable).

I suppose releases could be packaging the applications they contain but 
what for? That's just an extra unnecessary step there.

Some way to package releases could be cool for some things, but that 
wouldn't be the same as what is done in the Java world. Production 
systems don't need Erlang installed to run Erlang systems, the Erlang 
system is included in your release.

On 10/30/2012 06:58 PM, Andrew Berman wrote:
> 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 <erlang@REDACTED
> <mailto:erlang@REDACTED>> wrote:
>
>     On Tue, Oct 30, 2012 at 6:31 PM, Joe Armstrong <erlang@REDACTED
>     <mailto:erlang@REDACTED>> wrote:
>      > On Tue, Oct 30, 2012 at 6:17 PM, Andrew Berman <rexxe98@REDACTED
>     <mailto:rexxe98@REDACTED>> 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.timothy@REDACTED <mailto: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 <mailto:erlang-questions@REDACTED>
>      >>> http://erlang.org/mailman/listinfo/erlang-questions
>      >>>
>      >>
>      >>
>      >> _______________________________________________
>      >> erlang-questions mailing list
>      >> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>      >> http://erlang.org/mailman/listinfo/erlang-questions
>      >>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>


-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu



More information about the erlang-questions mailing list