Align proto package paths and python generated package paths.

[Ricefrog]

Summary of changes

In python generated class context, all generated code *_pb2 is imported from keysight_chakra.infra or keysight_chakra.mlcommons

from keysight_chakra.infra import (
    infra_pb2,
    annotate_pb2,
)
from keysight_chakra.mlcommons import et_def_pb2

When compiling protos from this package with your own protos, .proto files import definitions like this:

import "keysight_chakra/infra/infra.proto";
import "keysight_chakra/infra/annotate.proto";
import "keysight_chakra/mlcommons/et_def.proto";

The imports are used in messages like this:

message Wrapper {
  keysight_chakra.infra.Infrastructure infrastructure = 1;
  repeated keysight_chakra.infra.Annotation infra_annotations = 2;
  keysight_chakra.mlcommons.Node node = 3;
}

[ajbalogh]

lgtm except for the makefile step to replace the package name

[ajbalogh]

I like the standardization on keysight_chakra.protobuf as the package name as it follows the google protobuf naming convention.

[thomas-am]

This would be a good example to follow:
https://github.com/googleapis/googleapis/tree/master/google

Except that we don't have a mono repo for all our protos in one place.

Here's the google chat API for example:
https://github.com/googleapis/googleapis/blob/master/google/chat/v1/chat_service.proto

See how it imports other .protos.
With that it would be something like keysight/chakra/v1alpha/*.proto

Versioning is something we should have, for example.
"protobuf" is only used for protobuf library related files.

[Ricefrog]

This would be a good example to follow: https://github.com/googleapis/googleapis/tree/master/google

Except that we don't have a mono repo for all our protos in one place.

Here's the google chat API for example: https://github.com/googleapis/googleapis/blob/master/google/chat/v1/chat_service.proto

See how it imports other .protos. With that it would be something like keysight/chakra/v1alpha/*.proto

Versioning is something we should have, for example. "protobuf" is only used for protobuf library related files.

I see. Maybe we could do

keysight_chakra/infra/*.proto
keysight_chakra/mlcommons/et_def.proto

to make a distinction between our custom protos and et_def.proto, which we pull directly from mlcommons.

As for having versioning in the directory structure, is it something we could put off until we know there is active third-party consumption of these protos?

[ajbalogh]

why are we including generated code? it should only be proto files - the generated code comes as part of the package at build time.

[Ricefrog]

why are we including generated code? it should only be proto files - the generated code comes as part of the package at build time.

I forgot to update .gitignore and accidentally pushed the generated code. I'll undo that