Skip to content

JRuby fails to bundle #11

Open
Open
JRuby fails to bundle#11

Description

@aemadrid
aemadrid
opened on Mar 18, 2015

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

Activity

  1. bschwartz commented on Mar 19, 2015

    @bschwartz
    bschwartz
    on Mar 19, 2015
    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

  2. aemadrid commented on Mar 19, 2015

    @aemadrid
    aemadrid
    on Mar 19, 2015
    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?

  3. bschwartz commented on Mar 19, 2015

    @bschwartz
    bschwartz
    on Mar 19, 2015
    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 :)

  4. aemadrid commented on Mar 19, 2015

    @aemadrid
    aemadrid
    on Mar 19, 2015
    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?

  5. aemadrid commented on Mar 21, 2015

    @aemadrid
    aemadrid
    on Mar 21, 2015
    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions