might not be bug: false duplication report due to use of relative path instead of absolute path about protoreflect HOT 6 CLOSED

The introduce of InferImportPaths and it 'rewriting imports paths to fix mismatching ones' sounds a good idea to me, though it didn't work for this case, I'll look into it.

@MUCZ, it is possible that the InferImportPaths functionality might now work for your case, as of #575.

from protoreflect.

when i run protoc -I.. -I. --go_out=. f/f1/*.proto inside folder test, i found the same error, so it turns out that this is not a problem of protoreflect/parse but of the protoc design. it might not be the right place but i do want to ask this question: why not store the absolute path?

from protoreflect.

an interesting thing is that i can parse "f/f1/f1.proto" or "f/f1/f2.proto" singly with no problem, using the main.go above or with protoc, both work, but i can not parse both at the same time... i can understand how but not why it's designed this way...

from protoreflect.

The file's relative path is part of its identity and is also used for reflection purposes at runtime. For this reason, the absolute path is not suitable, because then the file's identity could change based on the environment in which it was compiled -- one machine could have the repo checked out into a different directory, so the absolute path is completely different from another user. Since the paths are baked into the resulting generated code, this would lead to runtime problems. For more information, check out this page: https://buf.build/docs/reference/protobuf-files-and-packages#imports

The protoparse package in this repo does actually provide a flag that may fix what you are seeing, though it is not a feature supported by protoc. On the Parser, set the InferImportPaths field to true, and it will try to rewrite imports so that file names and imports all match, even if you use different relative paths to refer to the same file.

from protoreflect.

The file's relative path is part of its identity and is also used for reflection purposes at runtime. For this reason, the absolute path is not suitable, because then the file's identity could change based on the environment in which it was compiled -- one machine could have the repo checked out into a different directory, so the absolute path is completely different from another user. Since the paths are baked into the resulting generated code, this would lead to runtime problems. For more information, check out this page: https://buf.build/docs/reference/protobuf-files-and-packages#imports

The protoparse package in this repo does actually provide a flag that may fix what you are seeing, though it is not a feature supported by protoc. On the Parser, set the InferImportPaths field to true, and it will try to rewrite imports so that file names and imports all match, even if you use different relative paths to refer to the same file.

Thank you for your reply! The doc you referred is really helpful, I was facing exactly what it describes:

If you're using protoc, this is an easy mistake to make: the flexibility of the command-line interface actually lends itself to doing this and ending up compiling with mismatching paths.

The introduce of InferImportPaths and it 'rewriting imports paths to fix mismatching ones' sounds a good idea to me, though it didn't work for this case, I'll look into it.

from protoreflect.

The introduce of InferImportPaths and it 'rewriting imports paths to fix mismatching ones' sounds a good idea to me, though it didn't work for this case, I'll look into it.

@MUCZ, it is possible that the InferImportPaths functionality might now work for your case, as of #575.

That's great! Thank you for the fix! I think this can be closed now.

from protoreflect.