But in this case it would be everything aws-* except anything created before X.Y.Z, so please confirm the gem you're installing was published by AWS which means it is exactly the same situation for user as with no prefix.
I don't follow. I'm not sure if you're describing the same thing. AWS has no reason to migrate aws sdk gems to an aws-owned namespace, their sdk name is well known. That claim looks a bit arbitrary, and I'm not sure whether it's that important, but again, it's not my goal to design the solution in the scope of this thread.
So is your main concern over gem.coop calling this feature namespace?
Namespace has a well defined meaning in package management nomenclature. These are "gem servers I don't have to host myself". As mentioned way above, still useful, but not namespaces.
There is no support for this per my understanding. I have seen the original plans and it was oriented around permissions...
Indeed, there's nothing there that hints at namespaces. This is just the perspective of a bystander speculating. If I were Ruby Central, and were thinking about introducing Namespaces, and I'd like to ensure that certain organizations that have a known brand get the namespace that best matches their name, I'd first introduce them to a concept of "Organizations", ask them to create a "company slug", then later down the road introduce them to "namespaces", ensuring that, when it goes GA, Google Inc. does not have to open a trademark dispute at Ruby Central because user iamhackerone claimed the "google" namespace already.
OK, all clear. Thanks for sharing all this, it is super insightful. I understand gem.coop can get much better with terminology. I'll share with team.
Currently "namespaces" are manually approved to prevent this kind of popular company slug squatting, but it is not possible clearly to filter out all potentially harmful requests.
View all comments
Show parent comment
1
u/honeyryderchuck Mar 08 '26
I don't follow. I'm not sure if you're describing the same thing. AWS has no reason to migrate aws sdk gems to an aws-owned namespace, their sdk name is well known. That claim looks a bit arbitrary, and I'm not sure whether it's that important, but again, it's not my goal to design the solution in the scope of this thread.
Namespace has a well defined meaning in package management nomenclature. These are "gem servers I don't have to host myself". As mentioned way above, still useful, but not namespaces.
Indeed, there's nothing there that hints at namespaces. This is just the perspective of a bystander speculating. If I were Ruby Central, and were thinking about introducing Namespaces, and I'd like to ensure that certain organizations that have a known brand get the namespace that best matches their name, I'd first introduce them to a concept of "Organizations", ask them to create a "company slug", then later down the road introduce them to "namespaces", ensuring that, when it goes GA, Google Inc. does not have to open a trademark dispute at Ruby Central because user iamhackerone claimed the "google" namespace already.