Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

messages: Dependency on activesupport via (ruby-protobuf / protobuf-cucumber) #1096

Closed
jpaulgs opened this issue Jun 29, 2020 · 6 comments
Closed
Labels
⌛ stale Will soon be closed by stalebot unless there is activity language: ruby library: cucumber-messages 🔧 build Related to build / release process

Comments

@jpaulgs
Copy link

jpaulgs commented Jun 29, 2020

Summary

My API application does not include any of the Rails gems for development or production. However protobuf-cucumber has a dependency on activesupport and a very old version at that!

I totally understand why you moved away from google-protobuf (jruby support and latest RVM support) but I'd prefer not include activesupport...

Expected Behavior

Current Behavior

Possible Solution

Is it possible to revert back to google-protobuf and lock the RVM version to the latest supported?

Steps to Reproduce (for bugs)

Context & Motivation

Keeping my Gemfile.lock as small as possible

Your Environment

@luke-hill luke-hill transferred this issue from cucumber/common Jun 29, 2020
@luke-hill
Copy link
Contributor

Sorry I mis-read this. Sorry mybad, it was in the correct repo to start with.

@luke-hill luke-hill transferred this issue from cucumber/cucumber-ruby Jun 29, 2020
@luke-hill
Copy link
Contributor

luke-hill commented Jun 29, 2020

So you've raised 2 points.

  1. Revert back to older gem google-protobuf
  2. Lock rvm version to higher version
  • The google-protobuf gem, we were having a lot of issues trying to get official JRuby support from them. Essentially it was you were on your own. Furthermore the new protobuf gem (As explained here: cucumber-messages: Use pure-Ruby protobuf implementation (experimental) #813) Is actually a pure ruby version, and not a compiled version. This makes testing / usage on windows based systems a lot easier. Also alongside that PR aslak had to do some patches on their end, which took a while to get merged in.

  • We have a highly coupled system with messages / tags e.t.c. all of which require co-dependencies. For now we are in the 2.3 / 2.4 support phase. So the next step I would imagine is getting everything on 2.4 minimum (I envisage this will be happening soon).

2.4 only went EOL 3 months ago, so it is still reasonably up to date. I know down the line we will inevitably get rid of support for 2.4, but for now it's not too much hassle to support it.

@aslakhellesoy
Copy link
Contributor

Because we couldn't wait for our pull requests to be merged, we forked ruby-protobuf/protobuf and released it as cucumber-protobuf:

https://github.com/cucumber/cucumber/blob/bc428c4296f8e12735c923f07d00b71e15715d31/messages/ruby/cucumber-messages.gemspec#L25-L28

The library only seems to be using activesupport for gRPC, which we do not use. We should be able to remove activesupport and the code depending on it and make a new release.

@jpaulgs would you be able to help us with a PR for that?

@stale
Copy link

stale bot commented Aug 29, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs.

@stale stale bot added the ⌛ stale Will soon be closed by stalebot unless there is activity label Aug 29, 2020
@stale
Copy link

stale bot commented Sep 5, 2020

This issue has been automatically closed because of inactivity. You can support the Cucumber core team on opencollective.

@ZimbiX
Copy link

ZimbiX commented Feb 4, 2021

PR fix submitted: cucumber-attic/protobuf#2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⌛ stale Will soon be closed by stalebot unless there is activity language: ruby library: cucumber-messages 🔧 build Related to build / release process
Projects
None yet
Development

No branches or pull requests

4 participants