added a comment - - edited
Thanks that is much clearer.
Devops means often the same term carries very different meanings depending on whether the person comes from dev. or ops. background.
Devs are likely to think namespace refers to the usage context, as I did, e.g. 'server::web::nginx'
I think a `vendor` attribute is less ambiguous, and also descriptive. However, I also think it does not directly tackle the actual problem.
While the ticket mentions only that `name` data be required in metadata, there does seem to be an implicit understanding that `name` data will have specific characteristics.
Specifically, be the name of the cookbook as it is known in other cookbooks' `depends` lists. This seems to be a more intrusive change than just requiring a name attribute.
Finally, my initial reaction is that too much dependency mgt implementation detail is leaking into the cookbook metadata. Or equivalently - the cookbook is constraining how a dep mgt tool goes about mapping cookbook dependencies.
The actual problem:
The `depends` list of a cookbook needs to be mapped to another cookbook, the artifact to be identified.
It seems this is directly resolved, without being implementation specific, by requiring `replaces`, or `depends_name` or some such attribute in the metadata, plus version number.
This leaves people free to use `name` as they currently do, or do not, and embed vendor (or namepsace) data where ever and however they like. That is, some will continue to do this in a repo account name, some in the repo name, some using a sub-folder name, etc., etc.
It is trivial to show current examples where adding the suggested namespace leaves the actual problem unsolved - just consider any of the repo's named 'chef-<cookbook>`, e.g. chef-rvm, adding the vendor to the name space, e.g. fnichol, and you still don't know that this cookbook should satisfy another cookbook's `depends rvm`.
Adding a name or namespace/vendor attribute can be made to work, but will require many more changes to be made to how people are currently organized.
Can you give an example where `replaces` or `depends_name` + `version` doesn't solve the artifact id problem. Or have I misread the references to dep mgt tools, and there is some other "actual problem" being addressed?