[erlang-questions] Turning rebar into a package manager

[Andrew Berman]

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> wrote:

> On Tue, Oct 30, 2012 at 6:31 PM, Joe Armstrong <erlang@REDACTED> wrote:
> > On Tue, Oct 30, 2012 at 6:17 PM, Andrew Berman <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>
> >> 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
> >>>
> >>
> >>
> >> _______________________________________________
> >> 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/ca70559f/attachment.htm>