[chef] Re: Re: Re: Re: in-house berks-api cookbook naming conflicts

[Torben Knerr < >]

On Wed, Jan 7, 2015 at 12:52 AM, Noah Kantrowitz 
<
 >
 wrote:
>
> On Jan 6, 2015, at 3:46 PM, Torben Knerr 
> <
 >
>  wrote:
>
>> There was https://tickets.opscode.com/browse/CHEF-4027 once, but it
>> seems it had not been migrated to the Github issues (at least I
>> couldn't find it there).
>>
>> And what's so bad about referencing Git repos from a Berksfile?
>
> You have to do it everywhere individually rather than relying on 
> centralized release processes. Definitely doable on a small scale, but it 
> can rapidly get unsustainable.
>

But isn't that the same as updating a cookbook version? You have to do
that in every place you want the new version, too.

Maybe we are just talking about continous integration vs. locking deps
for a release here?

>
>> It's much more explicit and transparent than overloading namespaces
>> globally by pointing to a different "source" location.
>
> Having an explicitly isolated universe of cookbooks is just as explicit, 
> but it may throw some people for a loop if they are used to existing in the 
> community namespace. There has been much talk of how to handle namespace 
> management in the community, but little motion other than myself and a few 
> others waving arms. Until something changes there, you _must_ treat the 
> cookbook namespace as globally flat and thus if you want to control it you 
> need to make your own bubble universe off the side.
>

It's only as explicit if you look at the whole universe (and there
might be more than one afaiu), not if you look at individual projects.
And how can I tell that cookbook-xyz 1.0.0 in my private universe is
actually a fork of the community cookbook-xyz 1.0.0 in an internal
repo? Would this information get lost or does the /universe endpoint
know about that and tell you if you ask?

Cheers,
Torben

> --Noah