v1.0.0 attempts to `require_relative` non-existent path
Problem
Attempting to require 'rackup' with v1.0.0 fails with:
`require_relative': cannot load such file -- /Users/owenstephens/.rbenv/versions/3.1.3/lib/ruby/gems/3.1.0/gems/rackup-1.0.0/lib/rackup/handler
Reproduction
An example Gemfile:
source "https://rubygems.org"
gem "rails", '7.1.2'
gem "redis-rack", "2.1.4" # Depends on Rack < 3
after bundle installing, attemping bundle exec ruby -rrackup -e 'p 42' errors as above.
Background
We're midway through upgrading our app to Rails 7.1; we now depend on Rails 7.1, but do not yet depend on Rack 3, due to a third-party dependency that doesn't support Rack >= 3. We also use Tapioca to generate RBI files. As part of the RBI generation process, the app dependencies are required, including rackup.
I just ran into this problem too. The problem is that the rackup v1.0.0 release doesn't contain any files. It is a broken package.
It seems like the v1.0.0 release has an unlocked gemspec so if you're using Rack v2 you'll only get rackup v1.0.0 and have this problem :-(
Because rackup >= 2.0.0 depends on rack >= 3
and Gemfile depends on rack ~> 2.2,
rackup >= 2.0.0 cannot be used.
So, because Gemfile depends on rackup ~> 2.1,
version solving has failed.
The solution is not to use rackup or add to your gemfile until you upgrade to Rack v3.
I might recommend going so far as to pulling the v1.0.0 release since it is obviously broken.
And could we perhaps get a new release that's not broken?
Ping. Anyway any of us could help get a fix out for this?
Ping.
Sorry, I have not been getting any notifications. Probably best to mention someone by name in the future if you aren't getting any traction.
Let me take a look at what's gone wrong here.
Okay, this should be fixed in v1.0.1
Yes, it's intended as a "fake" release for Rack 2.x - otherwise adding rackup as a gem (intended for Rack 3) will cause problems when used with Rack 2.