[chef] Re: Re: RE: Re: Re: Re: Re: Re: [RFC] github.com/cookbooks

[Mark Van De Vyver < >]

On Thu, Nov 15, 2012 at 4:29 PM, John Dewey 
<
 >
 wrote:
> IMO the community site should be the canonical list of cookbooks.
>
> Some of you may not be ruby developers, or new to ruby gems.  One time at
> band camp a similar thing happened with ruby gems.   Github hosted ruby gems
> with gem names such as <github_id>-<gem_name>.  Eventually gem cutter came
> around, and we all rejoiced.  I'd just hate to fragment things with yet
> another cookbook location.

This might be a difference of opinion, but to my mind fragmentation is
guaranteed/encouraged when you choose to use Git.
What we are trying to do is not have to depend on a canonical source
for _production_ deployments:
- It is a source that tracks multiple vendors/individuals.
- won't delete repos
- serves as the source for cookbooks.io

In turn cookbooks.io is aimed at production deployments, i.e. no git history.
We'd like to get to a point where someone can run a script and
replicate www.cookbooks.io under their own ip/name.  Whether that is
public or private is up to them. This appeals in chef-solo use cases
where you'd like to have several cookbook sites to fall back to, e.g.
one on AWS one on Rackspace, one under your desk, etc.
This is the idea. We are not there yet.

> What if we did something wacky, bare with me, this isn't all that thought
> out.  Rather than uploading cookbooks we upload metadata about a cookbook
> and manage tagging of the repo much like ruby's bundler does when releasing
> a gem with `rake release`.  Maybe `knife release` … ? :)
>
> We are then imposing the convention of people developing in git, and using a
> common practice of tagging upon a release.  The community site simply
> maintains metadata, and an API for tools (such as librarian/berkshelf/knife)
> to pull in a cookbook via it's respective git repo.
>
> Probably a wacky approach, but at least it prevents further fragmentation.

Like Linus I really don't see fragmentation as a problem. Rather,
encourage it and see what develops out of it.
I'm not saying gh/cookbooks and cookbooks.io encourages innovation in
the same way Git does (that's a high bar), but they do share the same
motivation.

> John
>
> On Wednesday, November 14, 2012 at 8:32 PM, Matt Ray wrote:
>
> I think if we (Opscode) and all other producers of Community cookbooks were
> to tag every uploaded version this would be a moot point but it hasn't
> happened. I'm sure we're open to suggestions for how to enforce this,
> especially in the case where Community cookbooks might not be originating
> from GitHub or even git repos (gasp). Can we somehow make the Community site
> support this without creating yet another place to find cookbooks?
>
> Thanks,
> Matt Ray
> Senior Technical Evangelist | Opscode Inc.
> 
 
>  | (512) 731-2218
> Twitter, IRC, GitHub: mattray
> ________________________________
> From: Jesse Campbell 
> 
 
> Sent: Wednesday, November 14, 2012 9:26 PM
> To: 
> 
 
> Subject: [chef] Re: Re: Re: Re: Re: [RFC] github.com/cookbooks
>
> Biggest problem I run into with the opscode community cookbook site is that
> it isn't a git repo, so i have to download files, so if i make changes, i
> can't easily merge in upstream changes.
> The opscode cookbooks are also in https://github.com/opscode-cookbooks, but
> those are dev versions, not the released versions, so i can't use them
> without possibly running into untested/broken code.
>
> Basically what i want is for the opscode community cookbook site to allow
> running a git clone of everything it holds, instead of being a repository of
> zip files.
>
> -jesse
>
> On Wed, Nov 14, 2012 at 6:22 PM, AJ Christensen 
> <
 >
>  wrote:
>
> Are there overwhelming issues with the Opscode Community cookbook site
>
>