#namespace conflicts
heady seal
Good point, but interestingly it's actually a Go SDK specific problem; I don't believe it's an issue in Python modules for instance. We already do automatic namespacing on the graphql level, this is only happening because we put the module's codegened client in the same go package as the user code.
If it was instead e.g. under ./dag/ then you'd be able to name something Container and still use the core type dag.Container too. And anyone consuming your module would be able to use both too due to the namespacing already in place (dag.Container for the core type, dag.YourModuleNameContainer for the custom one)
The other option of course is to rename everything from core in the codegen to be e.g. CoreContainer, CoreDirectory, etc. But I think I like that less
jolly kindle
the most annoying thing about this is that Go doesn’t support relative imports, so moving to a dag subpackage would probably be a PITA
heady seal
the most annoying thing about this is that Go doesn’t support relative imports, ...
Yeah it would require that go lsp automatically finds the right dag and automatically imports it for you, but based on experience back in the cloak days where we did something more like this, I highly doubt go lsp will work smoothly for that...
One more idea: if you name an object the same way it's already going to be namespaced in graphql, then we just don't namespace it further
So if your module is named cool and you create an object named CoolContainer, then in the graphql schema we don't layer on more namespacing that would result in CoolCoolContainer. We just skip the namespacing in that case
Still not great, but might be a contender for least worst?
I guess it doesn't solve the problem of us introducing a new core type and breaking lots of existing modules...
jolly kindle
namespace conflicts