fractaledmind / enlitenment

A Rails application template script to lead your app to SQLite enlightenment.
44 stars 3 forks source link

Adding solid_queue fails if it's already in the Gemfile #5

Closed trinitytakei closed 2 months ago

trinitytakei commented 2 months ago

Describe the bug

This issue came up while testing the script on a JSP-based application, although probably relevant in general.

I ran the script inside my existing JSP-based app, and it failed with

[!] There was an error parsing `Gemfile`: You cannot specify the same gem twice with different version requirements.
You specified: solid_queue (~> 0.3.1) and solid_queue (>= 0). Bundler cannot continue.

This is because I was already using solid_queue. Surprising, I know!

What makes this tricky though, at least in the context of a JSP-based application, is that the gem is being loaded from Gemfile.jumpstart (rather than the 'normal' Gemfile) like so:

if Jumpstart.config.background_job_processor == "solid_queue"
  gem 'solid_queue', '~> 0.3.1'
  gem "mission_control-jobs"
end

You can unravel this rabbithole if you wish so by looking at the jumpstart.yml, checking the background_job_processor: xxx value etc.

The real question, though is: is it worth it?

It's obviously your call, but I personally don't think so. Who knows how many of these non-Railsy things are there in JSP - and Bullet Train, and whatever else.

But, perhaps it would make sense to guard against this in the future in 'standard' Rails apps, by looking in the 'standard' Gemfile?

To Reproduce

Run the script for an already existing app, in which Gemfile already contains solid_queue.

Expected behavior

The script should not choke on this, but change the original gem "solid_queue"... row to gem "solid_queue", github: "rails/solid_queue", branch: "main"

This might cause some gotchas too - what if the original gem "solid_queue"... was pinned to a version for a good reason? Even if it was not (just a 'bare' gem "solid_queue" line), it's now going to point at the main branch, which might cause issues down the road.

But again (my 2c), as with the JSP-Gemfile issue, I don't think enlitement should try to solve this.

fractaledmind commented 2 months ago

This is a useful bug report that will require a bit more thinking on my end on how I want to proceed. But this testing is already quite useful. Thanks. To keep testing, you can copy the template file down locally, comment out that one line, and run again to find new issues.

fractaledmind commented 2 months ago

@trinitytakei: Just pushed a new version that checks the Gemfile.lock instead of the Gemfile to determine whether to add a gem. Give that a try.

fractaledmind commented 2 months ago

@trinitytakei: Can you confirm that this issue is fixed?

trinitytakei commented 2 months ago

@fractaledmind Didn't catch the original update for whatever reason. Checked now, all good!