gemspec is too permissive

[mark-dce]

ISSUE I've just tried generating an app from scratch (Dive-into-Hydra) using the current release candidate (which worked in April), but now I'm getting errors. The dependencies in the 'hydra' gem should be tight enough that a release doesn't break because of future version updates to dependent gems. Possibly, we're just not managing semver successfully in some dependency...

Gemfile

gem 'hydra', '9.1.0.rc1'

I also tested

gem 'hydra', github: 'projecthydra/hydra', branch: 'master'

ERROR

Started GET "/" for 10.0.2.2 at 2015-10-27 14:29:42 +0000
Cannot render console from 10.0.2.2! Allowed networks: 127.0.0.1, ::1, 127.0.0.0/127.255.255.255

Ldp::HttpError (STATUS: 503 ...):
  ldp (0.3.1) lib/ldp/client/methods.rb:108:in `block in check_for_errors'
  ldp (0.3.1) lib/ldp/client/methods.rb:106:in `tap'
  ldp (0.3.1) lib/ldp/client/methods.rb:106:in `check_for_errors'
  ldp (0.3.1) lib/ldp/client/methods.rb:24:in `head'
  active-fedora (9.1.2) lib/active_fedora/fedora.rb:41:in `init_base_path'
  active-fedora (9.1.2) lib/active_fedora/fedora.rb:5:in `initialize'
  active-fedora (9.1.2) lib/active_fedora.rb:207:in `new'
  active-fedora (9.1.2) lib/active_fedora.rb:207:in `fedora'
  active-fedora (9.1.2) lib/active_fedora/ldp_cache.rb:40:in `reset_cache_settings'
  active-fedora (9.1.2) lib/active_fedora/ldp_cache.rb:33:in `rescue in call'
  active-fedora (9.1.2) lib/active_fedora/ldp_cache.rb:24:in `call'
  activerecord (4.2.4) lib/active_record/migration.rb:377:in `call'
  actionpack (4.2.4) lib/action_dispatch/middleware/callbacks.rb:29:in `block in call'
  activesupport (4.2.4) lib/active_support/callbacks.rb:88:in `__run_callbacks__'
  activesupport (4.2.4) lib/active_support/callbacks.rb:778:in `_run_call_callbacks'
  activesupport (4.2.4) lib/active_support/callbacks.rb:81:in `run_callbacks'
  actionpack (4.2.4) lib/action_dispatch/middleware/callbacks.rb:27:in `call'
  actionpack (4.2.4) lib/action_dispatch/middleware/reloader.rb:73:in `call'
  actionpack (4.2.4) lib/action_dispatch/middleware/remote_ip.rb:78:in `call'
  actionpack (4.2.4) lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call'
  web-console (2.2.1) lib/web_console/middleware.rb:31:in `call'
  actionpack (4.2.4) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'
  railties (4.2.4) lib/rails/rack/logger.rb:38:in `call_app'
  railties (4.2.4) lib/rails/rack/logger.rb:20:in `block in call'
  activesupport (4.2.4) lib/active_support/tagged_logging.rb:68:in `block in tagged'
  activesupport (4.2.4) lib/active_support/tagged_logging.rb:26:in `tagged'
  activesupport (4.2.4) lib/active_support/tagged_logging.rb:68:in `tagged'
  railties (4.2.4) lib/rails/rack/logger.rb:20:in `call'
  actionpack (4.2.4) lib/action_dispatch/middleware/request_id.rb:21:in `call'
  rack (1.6.4) lib/rack/methodoverride.rb:22:in `call'
  rack (1.6.4) lib/rack/runtime.rb:18:in `call'
  activesupport (4.2.4) lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'
  rack (1.6.4) lib/rack/lock.rb:17:in `call'
  actionpack (4.2.4) lib/action_dispatch/middleware/static.rb:116:in `call'
  rack (1.6.4) lib/rack/sendfile.rb:113:in `call'
  railties (4.2.4) lib/rails/engine.rb:518:in `call'
  railties (4.2.4) lib/rails/application.rb:165:in `call'
  rack (1.6.4) lib/rack/lock.rb:17:in `call'
  rack (1.6.4) lib/rack/content_length.rb:15:in `call'
  rack (1.6.4) lib/rack/handler/webrick.rb:88:in `service'
  /home/vagrant/.rvm/rubies/ruby-2.2.3/lib/ruby/2.2.0/webrick/httpserver.rb:138:in `service'
  /home/vagrant/.rvm/rubies/ruby-2.2.3/lib/ruby/2.2.0/webrick/httpserver.rb:94:in `run'
  /home/vagrant/.rvm/rubies/ruby-2.2.3/lib/ruby/2.2.0/webrick/server.rb:294:in `block in start_thread'

NOTE: I'm running in a VM using port forwarding, hence the 'cannot render console' warning.

[jcoyne]

I think the problem is you are not using a supported version of Fedora. As Fedora is not a gem it can't be constrained by the gemspec

[mark-dce]

If that's the issue, then we probably need to give instructions (at least in dive) and possibly in the Hydra readme on how to specify the version of hydra-jetty being used.

[awead]

The error mentions IPs... is it related to: https://github.com/projecthydra/hydra-head/commit/8f7df6e664058308610e770e3eac48208cdab2c2

[mark-dce]

@awead I'm pretty sure the IP issue is just because I'm running in a VM and rails doesn't want to give the the console over a forwarded port.

[mark-dce]

I just confirmed Justin's diagnosis - running against hydra-jetty release v8.3.1 works without issue.

Is there any way we can pin the hydra release to a hydra-jetty release so new developers (or not bright ones like me) don't run into this issue if they're trying to use the gem in development environments when newer versions of hydra-jetty have been released (particularly with incompatible fedora or solr version)

Note: I tried explicitly setting JETTY_ZIP before downloading and it didn't work. I ended up having to edit the hydra_jetty_version in my local copy of the jetty wrapper gem itself - I will file an issue on jetty-wrapper too.

$ JETTY_ZIP="https://github.com/projecthydra/hydra-jetty/archive/v8.3.1.zip" rake jetty:download
I, [2015-10-27T10:30:27.623066 #24568]  INFO -- : Downloading jetty at https://github.com/projecthydra/hydra-jetty/archive/master.zip ...

i.e. it's downloading "master", not the specific release I'm trying to set.

[jcoyne]

You can't pin Hydra to a specific hydra-jetty release. But you can do:

require 'jettywrapper'
Jettywrapper.hydra_jetty_version = 'v8.3.1'

in your Rakefile.