Foreman: Mettre à jour la dépendance de thor

Est-ce encore maintenu ?

@alaxalves, nous venons de passer à renoncer , semble être un remplacement instantané.

@alaxalves, nous venons de passer à renoncer , semble être un remplacement instantané.

@mfilej C'est génial, mais comment continuer à utiliser Foreman dans une application Rails ?

@alaxalves Qu'entendez-vous exactement par "utiliser dans une application rails" ? Utilisez-vous autre chose que l'exécution de processus ? Pour nous, il s'agissait simplement d'installer forego sur nos machines et serveurs de développement (images docker) et de changer la commande de foreman start à forego start .

@alaxalves Qu'entendez-vous exactement par "utiliser dans une application rails" ? Utilisez-vous autre chose que l'exécution de processus ? Pour nous, il s'agissait simplement d'installer forego sur nos machines et serveurs de développement (images docker) et de changer la commande de foreman start à forego start .

Je voulais dire l'utiliser comme un bijou.

@alaxalves désolé, je ne sais pas ce que cela signifie. Dans notre cas, nous venons de supprimer la gemme du contremaître de nos fichiers gemmes. Est-ce que quelque chose dans votre code repose sur la gemme de contremaître ?

@alaxalves désolé, je ne sais pas ce que cela signifie. Dans notre cas, nous venons de supprimer la gemme du contremaître de nos fichiers gemmes. Est-ce que quelque chose dans votre code repose sur la gemme de contremaître ?

Oui, je l'utilise. Mais je vais commencer à utiliser forego. Je ne voulais tout simplement pas l'installer en tant que pkg ou quelque chose comme ça. J'aimerais continuer à utiliser comme dépendance définie dans mon Gemfile. En tout cas merci pour votre temps :sourire:

Je rencontre exactement le même problème lors d'une mise à niveau vers Rails 6.0.0, qui dépend d'une version plus récente de thor. Bundler le résout en rétrogradant foreman, dotenv et thor. J'ai essayé de forcer la dernière version de foreman dans le Gemfile et cela montre le problème de dépendance :

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)

L'exécution de la mise à jour du bundle ne résout pas non plus le problème.

Autant que je sache, Forego n'est pas écrit en Ruby, ce n'est donc pas une bonne solution de contournement car cela ajoutera une autre dépendance au projet.

Je vous suggère fortement de ne pas inclure foreman dans votre Gemfile. J'ai écrit mon raisonnement ici:

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

Génial. J'ai jeté un coup d'œil à votre écriture et c'est parfaitement logique. Merci d'avoir clarifié cela... et merci d'avoir mis le contremaître là-bas !

Je vous suggère fortement de ne pas inclure foreman dans votre Gemfile. J'ai écrit mon raisonnement ici:

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

Pourquoi ne pas utiliser gem 'foreman', require: false au lieu de ne pas l'inclure ?
C'est ce que j'utilise pour beaucoup d'outils de développement (comme les linters, etc...), même la documentation de certaines gemmes semble être correcte avec require: false (cf : https://github.com/rubocop-hq/rubocop #installation, https://github.com/sds/haml-lint#installation)

@ddollar Je ne suis pas d'accord avec https://github.com/ddollar/foreman/wiki/Don 't-Bundle-Foreman.

Foreman chez @cultureamp est un outil de développement, un peu comme rubocop, rspec-rails, cucumber, factory_bot, etc. Il est _pratique_ de l'avoir spécifié dans le Gemfile , car il sera alors disponible pour nous immédiatement , tout comme ces autres outils.

Je le préciserais ainsi :

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

En l'ajoutant au groupe development , cela signifierait qu'il n'est pas disponible en production et n'est pas un vecteur de vulnérabilité.

Donc, avec cela à l'esprit, cela signifierait que le Gemfile.lock reçoit ces dépendances :

foreman (0.85.0)
  thor (~> 0.19.1)

Cela provoque des conflits avec la nouvelle gemme railties 6.0, car elle dépend de thor de >= 0.20.3, < 2.0 .

Je crois fermement que foreman _devrait_ être placé dans le Gemfile d'une application parce que _c'est un outil de développement_ et je crois également fermement que la dépendance thor de foreman devrait être mise à jour, ou du moins assouplie.

Même si Foreman ne devrait pas être mis dans Gemfiles, à quoi bon le maintenir obstinément dépendant d'une version depuis longtemps dépassée de Thor ?

Tout changement peut introduire des bogues, je renverserais donc cette question. En l'absence d'une vulnérabilité de sécurité ou d'une nouvelle fonctionnalité souhaitée, quel est l'avantage de mettre à niveau une dépendance qui pourrait introduire des modifications avec rupture ?

1. Les bibliothèques plus anciennes sont plus difficiles à mettre à niveau. Plus vous attendez, plus il sera difficile de décider de mettre à niveau. (Si ce ne sera pas plus difficile à l'avenir, c'est parce que la bibliothèque n'a pas beaucoup de changements incompatibles, donc ce ne serait pas difficile maintenant non plus.) Il est logique de ne pas perdre de temps sur des cycles de mise à niveau trop fréquents, mais six ans c'est long.

2. Les vulnérabilités de sécurité dans les anciennes versions de logiciels aléatoires sont moins susceptibles d'être découvertes publiquement, car les gens ne les utilisent pas ou ne les examinent pas, mais les vulnérabilités existeraient néanmoins. (Mises en garde pour les anciens ordinateurs centraux, etc., mais il s'agit d'un logiciel Github connecté à Internet.) Bien sûr, les vulnérabilités de sécurité dans thor sont sans aucun doute de faible priorité, car il s'agit d'un outil de ligne de commande local, en particulier dans le cas d'utilisation du contremaître. Mais cela signifie que selon votre politique, il est peu probable que thor soit mis à niveau, jamais. (Une vulnérabilité de sécurité a été signalée dans thor, mais elle a été fermée car "Thor est un outil système qui ne recevra probablement pas d'entrée utilisateur", https://github.com/erikhuda/thor/issues/514).

3. Incompatible avec d'autres bibliothèques, le problème est ici. Il existe une solution de contournement, mais mettre le contremaître dans le Gemfile est clairement un cas d'utilisation courant et utile. Il y a apparemment même d'autres gemmes qui dépendent du contremaître et doivent donc le mettre dans leur Gemfile. (Cela pourrait également affecter la qualité du test, si les utilisateurs ont un système mixte à jour alors que l'environnement de test a une installation nue avec d'anciennes versions, bien que cela ne soit pas probable dans le cas du contremaître/thor.)

En conclusion, d'un point de vue technique, cela semble être un appel proche, mais d'un point de vue des systèmes et de l'écosystème, c'est essentiel, et le devient d'autant plus que les années passent (et je ne suis pas quelqu'un qui pense que "plus nouveau signifie mieux"). Vous pouvez penser que personne n'utilisera votre logiciel au moment où la dépendance thor aura dix ans, mais vous obtenez également des effets collatéraux où les gens décident d'arrêter d'utiliser foreman parce qu'il est incompatible ou semble non maintenu.

(En outre, il est possible que la mise à niveau de la dépendance prenne cinq minutes et ne cause aucun bogue.)