Refactor package structure to move generated code to language-specific folders #6
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR refactors the package structure used for Protobuf files and for each language.
The code for each language -- including Protobuf -- is moved to its own folder, e.g.
/proto
,/go
,/python
, etc. Different languages have different packaging systems and conventions, and this allows the code layout to follow the conventions for each specific language. For example, Protobuf allows.proto
files for multiple packages to be in the same directory, while Go requires that all.go
files in a folder have the same package name. Like Protobuf and Go, Python has a packaging system. But whereas all types within a Go package share the same namespace, Python namespaces types within a file (module) by the module name rather than the package name. This leads to a different convention for packaging in Python than in Go. In Python, for example, even though the e2sub services span multiple Protobuf packages, all of the e2sub services can be members of the same Python package without creating naming collisions, and indeed that would be more consistent with conventional Python project structures.By separating the packages and code for each language into its own folder, we can layout the generated code for each language according to the language's conventions. Additionally, language-specific dependency management can be located in language-specific folders. For instance, the Go module root for the onos-api is now in the
/go
folder rather than in the onos-api root. Similarly, the/python
folder can include arequirements.txt
for instance.Finally, I restructured the package structure used in the
/proto
folder itself such that the folder hierarchy matches the package names. Theprotoc
plugins for some languages will work better this way. And I cleaned up thecompile-protos.sh
script to generate documentation separately from the bindings for each language.