Skip to content

Conversation

@aaronc
Copy link
Member

@aaronc aaronc commented Feb 4, 2022

Description

We ran into an issue trying to use orm options in packages which still are using gogo for msg and query servers. Because the orm proto files use buf managed mode and don't set go_package, an invalid go path gets generated and there's a build error for the gogo .pb.go files. Even if we set the go_package to the API module, this could sometimes fail because you can't reference pulsar generated code from gogo generated code.

So this PR generated those types in github.com/cosmos/cosmos-sdk/types/apicompat allows you to target these types from gogo using go package override with buf managed mode.


Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

// go_package_prefix:
// override:
// buf.build/cosmos/cosmos-sdk: github.com/cosmos/cosmos-sdk/types/apicompat
package apicompat
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is the best name. I also thought of calling it gogocompat but that isn't great either.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is fine since it won't be here long

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about api_gogo?

Copy link
Contributor

@robert-zaremba robert-zaremba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK. I would prefer to rename apicompat.

// go_package_prefix:
// override:
// buf.build/cosmos/cosmos-sdk: github.com/cosmos/cosmos-sdk/types/apicompat
package apicompat
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about api_gogo?

@aaronc
Copy link
Member Author

aaronc commented Feb 7, 2022

I actually realize this won't actually solve the problem. And we don't want more gogo types generated now

@aaronc aaronc closed this Feb 7, 2022
@aaronc
Copy link
Member Author

aaronc commented Feb 7, 2022

The fix that worked for us in regen is to add this to the gogo protoc options: Mcosmos/orm/v1alpha1/orm.proto=github.com/cosmos/cosmos-sdk/api/cosmos/orm/v1alpha1.

The issue with this PR is that if you use buf managed mode to set the go package to be types/apicompat that will affect all cosmos-sdk proto files and mess up their go_package.

The real fixes are either the M directive above or setting go_package to the API module. Gogo proto code should not import these pulsar types except for using the orm extensions.. and for this either solution is fine

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants