Foreman: 依存関係を更新する

これはまだ維持されていますか？

@alaxalvesは、 foregoに切り替えたばかりで、ドロップインの代替品のようです。

@alaxalvesは、 foregoに切り替えたばかりで、ドロップインの代替品のようです。

@mfilejこれは素晴らしいことですが、RailsアプリでForemanを使い続けるにはどうすればよいですか？

@alaxalves 「Railsアプリで使用する」とはどういう意味ですか？ プロセスの実行以外の目的で使用していますか？ 私たちにとっては、開発マシンとサーバー（Dockerイメージ）にforegoをインストールし、コマンドをforeman startからforego startに変更するだけでした。

@alaxalves 「Railsアプリで使用する」とはどういう意味ですか？ プロセスの実行以外の目的で使用していますか？ 私たちにとっては、開発マシンとサーバー（Dockerイメージ）にforegoをインストールし、コマンドをforeman startからforego startに変更するだけでした。

私はそれを宝石として使うことを意味しました。

@alaxalves申し訳ありませんが、それが何を意味するのかわかりません。 私たちの場合、gemfilesからフォアマンgemを削除しました。 あなたのコードの何かが職長の宝石に依存していますか？

@alaxalves申し訳ありませんが、それが何を意味するのかわかりません。 私たちの場合、gemfilesからフォアマンgemを削除しました。 あなたのコードの何かが職長の宝石に依存していますか？

はい、使っています。 しかし、私はforegoを使い始めます。 pkgなどとしてインストールしたくありませんでした。 Gemfileで定義された依存関係として使い続けたいです。 とにかく、お時間をいただきありがとうございます：smile：

Rails 6.0.0へのアップグレードを実行するときに、これとまったく同じ問題が発生します。これは、thorの最新バージョンに依存します。 Bundlerは、フォアマン、dotenv、thorをダウングレードすることで解決しています。 Gemfileでフォアマンの最新バージョンを強制しようとしましたが、これは依存関係の問題を示しています。

Bundler could not find compatible versions for gem "thor":
  In snapshot (Gemfile.lock):
    thor (= 0.20.3)

  In Gemfile:
    foreman (~> 0.85.0) was resolved to 0.85.0, which depends on
      thor (~> 0.19.1)

    rspec-rails was resolved to 3.8.2, which depends on
      railties (>= 3.0) was resolved to 6.0.0, which depends on
        thor (>= 0.20.3, < 2.0)

バンドルアップデートを実行しても問題は解決しません。

私の知る限り、ForegoはRubyで記述されていないため、プロジェクトに別の依存関係が追加されるため、これは優れた回避策ではありません。

Gemfileにforemanを含めないことを強くお勧めします。 私はここに私の推論を書きました：

https://github.com/ddollar/foreman/wiki/Don't-Bundle-Foreman

素晴らしい。 私はあなたの記事を見ました、そしてそれは完全に理にかなっています。 それを明確にしてくれてありがとう...そしてフォアマンをそこに置いてくれてありがとう！

Gemfileにforemanを含めないことを強くお勧めします。 私はここに私の推論を書きました：

https://github.com/ddollar/foreman/wiki/Don't-Bundle-Foreman

gem 'foreman', require: falseを含めない代わりに使用しないのはなぜですか？
それは私が多くの開発ツール（リンターなど）に使用しているものです、いくつかの宝石のドキュメントでさえrequire: falseで大丈夫のようです（cf：https://github.com/rubocop-hq/rubocop ＃installation、https：//github.com/sds/haml-lint#installation）

@ddollarhttps : //github.com/ddollar/foreman/wiki/Don't-Bundle-Foremanに同意しません。

@cultureampのForemanは、rubocop、rspec-rails、cucumber、factory_botなどによく似た開発者ツールです。これをGemfileで指定すると、すぐに使用できるようになるので、_便利です_。 、他のツールと同じように。

私はそれを次のように指定します：

group :development do
  gem 'foreman', require: false
end

それをdevelopmentグループに追加することは、本番環境では利用できず、脆弱性のベクトルではないことを意味します。

したがって、それを念頭に置いて、 Gemfile.lockがこれらの依存関係を受け取ることを意味します。

foreman (0.85.0)
  thor (~> 0.19.1)

これにより、新しいrailties 6.0 gemとの競合が発生します。これは、 >= 0.20.3, < 2.0のthorに依存しているためです。

foremanはアプリケーションのGemfileに配置する必要があると強く信じています。これは、_それが開発者ツールであるため_であり、同様に、フォアマンのthor依存関係を更新するか、少なくとも緩和する必要があると強く信じています。

ForemanをGemfilesに入れるべきではないとしても、古くて古いバージョンのThorに頑固に依存し続けることのポイントは何ですか？

どんな変更でもバグを引き起こす可能性があるので、私はこの質問を好転させます。 セキュリティの脆弱性や必要な新機能がない場合、重大な変更をもたらす可能性のある依存関係をアップグレードすることの利点は何ですか？

1. 古いライブラリはアップグレードが困難です。 待つ時間が長くなるほど、実際にアップグレードする必要がある/アップグレードすることを決定するのが難しくなります。 （将来、それが難しくならないのであれば、それはライブラリに互換性のない変更があまりないためです。したがって、今も難しくはありません。）過度に頻繁なアップグレードサイクルに時間を無駄にしないのは理にかなっていますが、6年長い時間です。

2. ランダムに古いバージョンのソフトウェアのセキュリティの脆弱性は、人々がそれらを使用したり調べたりしていないため、公に発見される可能性は低くなりますが、それでも脆弱性は存在します。 （古代のメインフレームなどの警告ですが、これはインターネットに接続されたGithubソフトウェアです。）もちろん、これはローカルのコマンドラインツールであるため、特にフォアマンのユースケースでは、セキュリティの脆弱性の優先度は間違いなく低くなります。 しかし、これはあなたのポリシーの下では、トールがアップグレードされる可能性が低いことを意味します。 （セキュリティの脆弱性がthorで報告されましたが、「Thorはユーザー入力を受け取る可能性が低いシステムツールである」ため、クローズされました、https：//github.com/erikhuda/thor/issues/514）。

3. 他のライブラリと互換性がないため、ここで問題が発生します。 回避策はありますが、フォアマンをGemfileに配置することは、明らかに一般的で便利なユースケースです。 フォアマンに依存しているため、Gemfileに配置する必要のある他の宝石もあるようです。 （これは、テスト環境に古いバージョンがベアインストールされているときにユーザーが最新のシステムを混合している場合、テストの品質にも影響を与える可能性がありますが、フォアマン/トールの場合はそうではない可能性があります。）

結論として、技術的な観点からは緊密な呼びかけのように見えますが、システムとエコシステムの観点からは不可欠であり、年が経つにつれてますます大きくなります（そして私は「新しい方が良い」と考える人ではありません）。 依存関係が完全に10年になるまでに、誰もソフトウェアを使用しないと思うかもしれませんが、互換性がないか、保守されていないように見えるために、フォアマンの使用をやめるという副次的な影響もあります。

（また、依存関係のアップグレードに5分かかり、バグがゼロになる可能性があります。）