On Sun, Feb 26, 2012 at 2:18 PM, Jonathan Proulx <j...@jonproulx.com> wrote:
> On Sun, Feb 26, 2012 at 1:54 PM, Brian Troutwine <br...@troutwine.us> wrote:
>> I'm a big fan of using read-only submodules, usually to the upstream
>> project but sometimes to my own fork. The use of submodules makes
>> getting changes in from upstream trivial
>
> I agree that github is where it's at. On of the things I liked
> looking at chef (if I can mention competing systems :) was their
> integrated module system does a little git dance to (allegedly) make
> this all happen, I should probably look and see what they are
> actually doing in there.
It's slick, certainly. There's a tooling deficit _around_ Puppet, in
some part because there's a focus on general applicability. Much of
Chef's tooling breaks--or, at least, did--in the absence of git. I
wouldn't mind seeing a Golden Path of convention over configuration
come out of PuppetLabs, along with the related tooling. A heavy revamp
of the Forge to work not unlike rubygems for module producers and like
ruby-toolbox.com for consumers.
I seem to recall changes to the Forge being mentioned on this list,
but I don't recall the details provided, if any were given. As it is,
speaking an exclusive git/Puppet user, the Forge acts as an okay-ish
module search engine but doesn't add much value otherwise. Having to
upload release tarballs feels anachronistic and, frankly, I've not
bothered.
> One of my concerns with submodule is the need to treat them
> differently from other subtrees. Having a small team working on the
> configuration system would everyone need to remember (or remember to
> check) which modules were local and which were from the forge?
Yes, unfortunately. The git porcelain here isn't all that helpful.
I've seen a few projects discussed in #git that abstracts over the two
approaches, but I've not used them and the most popular--as I
understand it--hasn't seen an update in a year:
https://github.com/apenwarr/git-subtree
I'd imagine the cognitive load on folks will be less if you stick with
one approach or the other. I tend to get confused in projects that are
mixed, but that could be me projecting a personal deficiency as normal
and justifiable. :)
Certainly soliciting opinions in a git-specific mailing-list would not hurt.
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
Brian L. Troutwine
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
