Skip to content
This repository was archived by the owner on Aug 18, 2022. It is now read-only.

When the topmost and a leaf module share a name, we get an error. #16

Closed
Drvi opened this issue Aug 15, 2022 · 1 comment · Fixed by #17
Closed

When the topmost and a leaf module share a name, we get an error. #16

Drvi opened this issue Aug 15, 2022 · 1 comment · Fixed by #17

Comments

@Drvi
Copy link
Owner

Drvi commented Aug 15, 2022

So while making the change to preserve package names exactly without making them more “julian”*, I also deleted the code that made the individual module names unique. Now there is this edge case, when if the leaf module has the same name as to topmost module, you can’t import it because the names would clash (and we have to import it to namespace imported definitions).

There is this vector database, Milvus, which provides a ProtoBuf interface. The current ProtoBuf doesn’t handle it for some reason related to scope resolution, we do generate code that is valid except for one thing: there is a milvus.proto.milvus package used by this file which tried to import the topmost milvus module into the leaf milvus module so that we can reach stuff in milvus.proto.common module. To solve this, I propose:

When importing the topmost module, if the names clash, use an alias for it (i.e. import ...milvus -> import ...milvus as var"#milvus") and make sure that when fully qualifying imported names, we use the alias.

* We want to do this so that parsing fully qualified names from Any types has less runtime overhead.

Sounds good, @quinnj?

@quinnj
Copy link
Collaborator

quinnj commented Aug 15, 2022

Yeah, that sounds like a good solution to me

@Drvi Drvi closed this as completed in #17 Aug 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants