Rails.env vs RAILS_ENV

219

Je vois les deux dans les exemples lors de la vérification de l'environnement dans lequel on s'exécute. Qu'est-ce qui est préféré? Sont-ils, à toutes fins utiles, égaux?

ruby-on-rails Brad
la source

Réponses:

370

Selon les documents , #Rails.envencapsule RAILS_ENV:

    # File vendor/rails/railties/lib/initializer.rb, line 55
     def env
       @_env ||= ActiveSupport::StringInquirer.new(RAILS_ENV)
     end

Mais regardez spécifiquement comment il est emballé, en utilisant ActiveSupport::StringInquirer:

Envelopper une chaîne dans cette classe vous offre un moyen plus joli de tester l'égalité. La valeur retournée par Rails.env est encapsulée dans un objet StringInquirer donc au lieu d'appeler ceci:

Rails.env == "production"

vous pouvez appeler cela:

Rails.env.production?

Ils ne sont donc pas exactement équivalents, mais ils sont assez proches. Je n'ai pas encore beaucoup utilisé Rails, mais je dirais que #Rails.envc'est certainement l'option la plus attrayante visuellement en raison de l'utilisation StringInquirer.

Mark Rushakoff
la source
belle explication, merci! J'essaie également de trouver où RAILS_ENV est défini? Une idée??
brad
70
Il convient de mentionner qu'il Rails.envs'agit de la nouvelle norme, car elle RAILS_ENVest obsolète.
Ryan Bigg
4
Ryan, sur une ligne de commande, vous ne pouvez pas utiliser Rails.env. donc si c'est obsolète bientôt, qu'utiliseriez-vous sur la CLI?
pjammer
8
Vous utilisez Rails.env.production? vous protège contre les fautes de frappe qui changent réellement l'environnement comme ceci: RAILS_ENV = "production". Remarquez le signe = manqué.
Magne
Toute cette complexité ridicule pour que vous puissiez utiliser un point d'interrogation?
Compte à jeter
31

ENV['RAILS_ENV']est désormais obsolète .

Vous devriez utiliser Rails.envce qui est clairement beaucoup plus agréable.

superluminaire
la source
29

Avant Rails 2.x, la méthode préférée pour obtenir l'environnement actuel était d'utiliser la RAILS_ENVconstante. De même, vous pouvez utiliser RAILS_DEFAULT_LOGGERpour obtenir l'enregistreur actuel ou RAILS_ROOTpour obtenir le chemin d'accès au dossier racine.

À partir de Rails 2.x, Rails a introduit le Railsmodule avec quelques méthodes spéciales:

  • Rails.root
  • Rails.env
  • Rails.logger

Ce n'est pas seulement un changement cosmétique. Le module Rails offre des fonctionnalités non disponibles à l'aide des constantes standard telles que le StringInquirersupport. Il existe également de légères différences. Rails.rootne renvoie pas un simple Stringbuth une Pathinstance.

Quoi qu'il en soit, la meilleure façon d'utiliser le Railsmodule. Les constantes sont obsolètes dans Rails 3 et seront supprimées dans une future version, peut-être Rails 3.1.

Simone Carletti
la source
1
Pour info, d'après ce qui a été discuté ici , il semble que ces méthodes aient été introduites dans Rails 2.3, et non 2.0.
jrdioko
Nous utilisons 2.1.2 sur un projet. Rails.envfonctionne sans problème.
Benjamin Oakes
2

Comportement étrange lors du débogage de mon application: nécessite "active_support / notifications" (rdb: 1) p ENV ['RAILS_ENV'] "test" (rdb: 1) p Rails.env "development"

Je dirais que vous devez vous en tenir à l'un ou l'autre (et de préférence Rails.env)

JuYo
la source
2

Mise à jour: dans Rails 3.0.9: méthode env définie dans railties / lib / rails.rb

jgpawletko
la source