> 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 g...@github.com: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-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions