protobuf
protobuf copied to clipboard
protocolbuffers
Make it possible to have lowercase enums in Ruby
I have an enum that is something like this
enum status {
active = 0;
paused = 1;
}
My issue is when compiling it to a .rb I get a typeError due to this line https://github.com/google/protobuf/blob/f53f911793c3024976f80211e0c976f5cc51f88d/ruby/ext/google/protobuf_c/message.c#L546 I get it is a standart to use uppercase for Ruby constants, but it is not used only on Ruby and changing all my constants is not a real option for me as my project is already big. Is there a way to bypass that error. Thanks in advance
Just to check if my understanding is correct: that example proto file can't be used in Ruby, but the .proto file is already used in other languages so you can't easily change the enum values to use UPPERCASE?
I have the corresponding .rb of that .proto that, yes, is used in other languages so the change for uppercase would be a little bit difficult
Although the proto file is not conforming to proto style guide, as long as the protocol compiler doesn't fail on such proto files, the generated ruby code should work rather than failing at runtime. This needs to be fixed in the ruby runtime or ruby code generator.
I'd like to request this be re-opened. Using all-lowercase symbols is a common convention in Ruby, and the natural way to map a fixed set of symbols to Proto seems to be as an enum. In my use case, it's not feasible to simply rename the enum values, because they've already been serialized in a number of places. Enforcing a style guide seems like something a linter should do, not a compiler.
If this is as simple as removing an assertion, I'm happy to submit a PR.
@haberman @TeBoring Can you comment on this issue? It seems to me a bug in ruby code generator.
FWIW - it's not just a question of removing an assertion, because we declare Ruby constants with the names of the enum values, and Ruby doesn't allow declaring constants with an initial lowercase letter. This still seems to me like a bug in the Ruby generator, but one that might require breaking API changes to fix. (Alternatively, maybe there's a way to just warn + avoid declaring the constants in the case where lowercase names were used.)
Hi team, I understand this issue has been hanging for a while, but wondering is there a solution to it? I can see ruby-protobuf gem introduced a env var to upcase enum name, is it an option to do something similar? cheers
I don't see us prioritizing this in the near term. I think in the vague future we are likely to add some features that will make this kind of configuration more acceptable, but it won't move for a while.
I try to write a monkey patch to handle this case https://github.com/protocolbuffers/protobuf/pull/10454.
You're welcome to comment and show me how to make it solid or introduce any option.
could someone make it clear what's the new bug in this issue. I am not very clear if this issue has been solved...
When working on #10454, I notice that even in current codebase we can use
YourEnumType.resolve(:lowerCaseEnums)
to get the int number. So I may prefer to close this as having a workaround.
Auto capitalize can break existing code making use of JSON codec or the method above already.
UPDATE: The original purpose here can be only to define the constant following Ruby's rule. Let me try to narrow the change scope.
UPDATE2: I think the patch #10454 is ready to merge now. All tests passed locally:
rbenv global 3.1.2
bazel test //ruby:conformance_test
rbenv global jruby-9.3.7.0
bazel test //ruby:conformance_test_jruby --define=ruby_platform=java --action_env=PATH --action_env=GEM_PATH --action_env=GEM_HOME --verbose_failures
cd ./ruby/
bundle install
bundle exec rake test
rbenv global 3.1.2
bundle exec rake test
@JasonLunn @mkruskal-google shall we port the change to 21.x to get it in 3.21.8, or we will release a 3.22.0 recently? Both version works for me to include the patch into my gem.
22.x isn't scheduled yet, but it should get released by EOY. If you want to backport it to 21.x to get picked up in the next release that seems reasonable to me
@mkruskal-google Thank you. Pick at https://github.com/protocolbuffers/protobuf/pull/10708.