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

JRuby fails to bundle #11

Open
aemadrid opened this issue Mar 18, 2015 · 5 comments
Open

JRuby fails to bundle #11

aemadrid opened this issue Mar 18, 2015 · 5 comments

Comments

@aemadrid
Copy link

When bundling in JRuby for development it fails because of sys-proctable

/usr/local/var/rbenv/versions/jruby-1.7.18/bin/jruby --2.0 /usr/local/var/rbenv/versions/jruby-1.7.18/bin/bundle install
WARN: Unresolved specs during Gem::Specification.reset:
      ffi (>= 0)
WARN: Clearing out unresolved specs.
Please report a bug if this causes problems.
Fetching gem metadata from http://rubygems.org/.Retrying dependency api due to error (2/3): Bundler::MarshalError ArgumentError: marshal data too short
Retrying dependency api due to error (3/3): Bundler::MarshalError ArgumentError: marshal data too short


Resolving dependencies.....
Could not find sys-proctable-0.9.4 in any of the sources

Process finished with exit code 7
@bschwartz
Copy link
Member

Hi Adrian,

That's unfortunate. It's because of the dependency on nsq-cluster for testing. Ironically we moved to sys-proctable there for get better cross platform support (see: wistia/nsq-cluster@e46160d).

Looks like sys-proctable isn't planning to support JRuby anytime soon: djberg96/sys-proctable#18.

Any ideas for how to get around this? PR's welcome, of course!

Brendan

@aemadrid
Copy link
Author

I'll give it a try. My initial idea is to remove the hard dependency, already in my fork, and then in the tests check if it can be loaded. If it can't then display a warning and skip that test. Now I haven't checked if you can run any of the tests without it. What do you think?

@bschwartz
Copy link
Member

I think that sounds reasonable. It might be easier to try to do this at the nsq-cluster level though. We need nsq-cluster for pretty much all the nsq-ruby tests.

But nsq-cluster just needs sys-proctable for stopping nsqadmin, which none of these tests really need.

Hmm, this is a tricky problem :)

@aemadrid
Copy link
Author

Hmh, it seems then that we need to change the hard requirement at nsq-cluster and follow the whining idea when you try to stop nsqadmin? Basically try to load sys-proctable when you actually try to stop nsqadmin and raise the exception there. Or add a warning message at nsq-cluster load time and also raise the exception?

@aemadrid
Copy link
Author

Created this PR for nsq-cluster:

wistia/nsq-cluster#15

Please let me know what you think.

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

No branches or pull requests

2 participants