-
Notifications
You must be signed in to change notification settings - Fork 628
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
Update thor dependency #735
Comments
Is this even still being maintained? |
@alaxalves we just switched to forego, seems to be a drop-in replacement. |
@mfilej This is great, but how do we keep using Foreman in a Rails app? |
@alaxalves What exactly do you mean by "using in a rails app"? Are you using for something other than running processes? For us it was just a matter of installing forego on our development machines and servers (docker images) and changing the command from |
I meant using it as a gem. |
@alaxalves sorry, I don't know what that means. In our case we just dropped the foreman gem from our gemfiles. Does anything in your code rely on the foreman gem? |
Yes, I've been using it. But I'll start using forego. I just didn't want to install it as a pkg or something like it. I'd like to keep using as a dependency defined in my Gemfile. Anyway, thanks for your time 😄 |
I'm seeing this exact same issue when performing an upgrade to Rails 6.0.0, which depends on a more recent version of thor. Bundler is resolving it by downgrading foreman, dotenv and thor. I've tried forcing the latest version of foreman in the Gemfile and this shows the dependency issue:
Running bundle update doesn't resolve the issue either. As far as I'm aware Forego isn't written in Ruby so that's not a great workaround as it will add another dependency to the project. |
I highly suggest that you do not include https://github.com/ddollar/foreman/wiki/Don't-Bundle-Foreman |
Great. I had a look at your writeup and it makes perfect sense. Thanks for clarifying that... and thanks for putting foreman out there! |
Why not using |
@ddollar I disagree with https://github.com/ddollar/foreman/wiki/Don't-Bundle-Foreman. Foreman at @cultureamp is a developer tool, much like rubocop, rspec-rails, cucumber, factory_bot, etc. It is convenient to have this specified in the I would specify it like this:
By adding it to the So with that in mind, it would mean that the
This causes conflicts with the new I strongly believe that |
Even if Foreman should not be put in Gemfiles, what is the point of keeping it stubbornly dependent on a long outdated version of Thor? |
Any change can introduce bugs so I would turn this question around. In the absence of a security vulnerability or desired new feature what is the advantage of upgrading a dependency that could introduce breaking changes? |
In conclusion, from a technical perspective it seems like a close call, but from a systems and ecosystem perspective it's essential, and becomes moreso as the years drift by (and I'm not someone who thinks "newer means better"). You may think no one will use your software by the time the thor dependency is a full ten years old, but you also get collateral effects where people decide to stop using foreman because it is incompatible or appears unmaintained. (Also, there is the distinct possibility that upgrading the dependency will take five minutes and cause zero bugs.) |
Noting for reference: |
foreman depends on an old version of thor that is incompatible with up-to-date gems like Rails 6. The prevailing advice seems to be to leave out foreman from Gemfile, but this seems like a workaround. (We had a project for years with foreman in the Gemfile, no problems.)
In any event, why does foreman.gemspec reference a version of thor from 2014? Why not upgrade it?
See also #452, #653, (and #688, #725, etc.), as well as affecting other projects, e.g. bkeepers/dotenv#324
The text was updated successfully, but these errors were encountered: