Consider isolating protobuf files to avoid conflicts with other projects

[CMajeri]

Hello,

Golang's protobuf compiler bakes the name of the file used during compilation directly inside the generated source file, and tries to register it (see this long running thread golang/protobuf#1122).

Registering multiple files with the same name causes errors. This is not a blocking issue, since protoc will take the full path used, so running protoc a/common.proto and protoc b/common.proto will work, even if protoc -I a common.proto and protoc -I b common.proto will not.

Currently, the SDK is compiling (at least some of) its proto files, without prefixing them with any sort of path. This causes potential conflicts with projects importing the sdk. It would help reducing some friction if the proto files were compiled using a clear path.

I encountered this with the common.proto file, as our project also has a file with that name. While fixable on our end, it caused a lot of reworking our build process.

[0xivanov]

Hi @CMajeri , thanks for bringing this up. We will look into it.

[0xivanov]

Currently, the SDK is compiling (at least some of) its proto files, without prefixing them with any sort of path.

The proto generated files live in proto/... dir, so not sure how it would cause conflicts.

[CMajeri]

The paths where the files live does not matter, it's how protoc is called on them that does.

For instance, if you do protoc proto/common.proto it will reserve the name proto/common.proto, but if you do protoc -I proto common.proto it will reserve the name common.proto.
In go (at least using the common protobuf package), the name will become unusable for any other project trying to register the same name.

Ideally, the path should contain a reference to your repo/org, for instance, google's protobuf files usually live under google/... and we compile them by importing that whole directory.

On the other hand, this sdk comes with pre-compiled proto files, which have been generated without any prefix.

If you find you agree and want to fix it, it's a matter of recompiling the proto using appropriate scope for your include directives. It likely means changing the import directives in your .proto files to match the path as well.

So something like having files live under proto/hedera/..., replacing your imports with import "hedera/...", and then compiling with protoc -I proto hedera/...

[0xivanov]

The protoc command that we use looks something like this: protoc <some-options> services/hapi/hedera-protobufs/services/<file-name>.proto

I think we do have a prefix.

[0xivanov]

All our .proto files live in services/hapi/hedera-protobufs/services/ and they don't need to import each other with prefix. Not sure if we need to change the file structure for "isolation" to work.

[CMajeri]

This is very easy to reproduce:

I create two files:
main.go

package main

import (
	"fmt"

	"github.com/hiero-ledger/hiero-sdk-go/v2/proto/services"
)

func main() {
	tx := services.Transaction{}
	fmt.Println("Hello world", tx)
}

And common.proto

syntax = "proto3";
option go_package = ".;main";

message MyMessage {
  uint64 entry = 1;
}

And then

$ protoc --go_out=. ./common.proto 
$ go run .
panic: proto: file "common.proto" is already registered
                previously from: "github.com/hiero-ledger/hiero-sdk-go/v2/proto/services"
                currently from:  "main"
        See https://protobuf.dev/reference/go/faq#namespace-conflict

Additionally, this is a snippet from the scripts/generate_proto.go file:

	// generate proto files for services code

	cmdArguments := []string{
		"--go_out=proto/services/",
		"--go_opt=paths=source_relative",
		"--go-grpc_out=proto/services/",
		"--go-grpc_opt=paths=source_relative",
		"-Iservices/hapi/hedera-protobufs/services",
	}

^ Note the -Iservices/hapi/hedera-protobufs/services.
I don't know if this file is up to date, or if it's the one actually used to compile the proto, but if it is, it would explain the issue.