Ruby on Rails 3 - Reload répertoire lib pour chaque demande

Je suis en création d'un nouveau moteur pour rails 3. Comme vous pouvez le deviner, ce moteur est dans le répertoire lib de mon application.

Cependant, j'ai quelques problèmes de développement. En effet, j'ai besoin de redémarrer mon serveur à chaque fois que je change quelque chose dans le moteur.

Est-il un moyen pour éviter cela ?

Puis-je la force de rails pour recharger complètement le répertoire lib ou un fichier spécifique et de ses exigences pour chaque requête ?

Merci pour votre aide 🙂

InformationsquelleAutor Nicolas Guillaume | 2010-07-19

33

TL;DR
- mettre cela en config/application.rb
  
  config.eager_load_paths += ["#{Rails.root}/lib"]
- supprimer require consolidés pour votre lib fichiers
Aller!

Laissez-moi vous expliquer en détail.

Je ne sais pas pourquoi cette réponse est acceptée, car il ne permet pas de rechargement dossier lib sur chaque demande. J'ai d'abord pensé que cela fonctionne pour les Rails 2, mais la question indique clairement que c'était pour Rails 3 et la date de sortie de la 3.0.0 est antérieure à la date de la réponse.

D'autres réponses paraître compliqué ou n'offrent pas de solution réelle.

J'ai décidé d'étudier un peu les choses, parce qu'il a été me tracasse et j'ai même découvert que les gens ont une solution et il implique la sauvegarde fichiers lib à l'intérieur de app/models dans le développement puis en les déplaçant vers /lib lorsque vous avez terminé. Nous pouvons faire mieux, non?

Ma solution est testée contre:
- Rails 3.0.20
- Rails 3.1.12
- Rails 3.2.13
- Rails 4.0.0.rc1
Mettre ceci dans votre config/application.rb:
```
# in config/application.rb
config.eager_load_paths += ["#{Rails.root}/lib"]
```
Que c'est!™

Assurez-vous de le mettre ici car il sera pas de travail si vous le mettez dans config/environments/development.rb, par exemple.

Assurez-vous que votre supprimer tous les require consolidés pour votre /lib code depuis require déclarations seront également provoquer cette solution ne fonctionne pas.

Ce code est implicite dans votre code, donc si vous avez de l'environnement de contrôle (qui sont inutiles) et au lieu de le code ci-dessus, vous décidez d'écrire quelque chose comme ceci:
```
# in config/application.rb
config.eager_load_paths += ["#{Rails.root}/lib"] if Rails.env.development?
```
vous devriez regarder sur le vieux require états, puisqu'ils sont toujours requis sur tous les environnements de développement, dans ce scénario.

Donc, si vous décidez malgré tout de faire de l'environnement vérifie, assurez-vous que vous n'inverse vérifie pour exiger des déclarations. Sinon, vous allez vous faire piquer!
```
require "beer_creator" unless Rails.env.development?
```
Vous pourriez penser que l'écriture de tout le paragraphe à propos de quelque chose qui est inutile est également inutile, mais je pense que la population en garde contre quelque chose qui est nécessaire quand vous faites quelque chose de superflu, est également nécessaire.

Si vous souhaitez en savoir plus sur ce sujet, consultez ce petit tutoriel.
- C'est tout à l'arrière buck vous pouvez également utiliser de la charge sans la eager_load_path. Créer helper qui prennent la chaîne comme paramètre et l'utilisation de la charge si l'env est dev et si besoin env est prod. Si vous essayez, s'il vous plaît laissez-moi savoir si ça fonctionne 🙂
- Ne semble pas fonctionner sur des Rails 3.0.20 avec ou sans le '}' à la fin de la chaîne.
- Cela n'a pas fonctionné pour moi sur 3.2.13 -- au lieu de cela, après l'ajout de la eager_load_paths, tous mes autres fichiers (les contrôleurs de + modèles) arrêté arriver reloaded entre les demandes aussi! (Va revenir à la normale si je supprime cette ligne.) Bizarre. J'ai finalement obtenu le travail avec cette réponse: stackoverflow.com/a/10954365/1164573
- Êtes-vous en mesure d'obtenir que cela fonctionne dans les Rails 4.1? J'ai un question (avec prime) à ce sujet ici, mais n'ont pas trouvé encore de réponse.
- retrait de l'exiger des déclarations conduire à l'erreur suivante NameError (uninitialized constant ...
- Est-ce que ça va causer à recharger en mode de production ainsi? Si vous souhaitez uniquement en mode de développement?
- Réponse correcte. Confirmé cela fonctionne sur les Rails 6.J'ai également eu des sous-répertoires dans mon répertoire lib/ que j'avais à ajouter explicitement à config.eager_load_paths, ou bien ils ne serait pas chaud-reloaded. Toutes les classes que vous avez chargé dans l'aide d'une require déclarations ou require_relative instruction pas chaud rechargeable.
InformationsquelleAutor shime
49

Je ne pouvais pas obtenir tout ce qui précède à travailler pour moi, alors j'ai creusé dans les Rails de code un peu et est venu avec cette:

Nouveau fichier: config/initializers/reload_lib.rb
```
if Rails.env == "development"
  lib_reloader = ActiveSupport::FileUpdateChecker.new(Dir["lib/**/*"]) do
    Rails.application.reload_routes! # or do something better here
  end

  # For Rails 5.1+
  ActiveSupport::Reloader.to_prepare do
    lib_reloader.execute_if_updated
  end

  # For Rails pre-5.1 
  ActionDispatch::Callbacks.to_prepare do
    lib_reloader.execute_if_updated
  end

end
```
Oui, je sais c'est dégueulasse mais c'est un hack. Il pourrait y avoir une meilleure façon de déclencher un rechargement complet, mais cela fonctionne pour moi. Mon cas d'utilisation spécifiques est une application Rack monté sur Rails route donc j'ai besoin de recharger, j'ai travaillé dans le développement.

Essentiellement, ce qu'il fait c'est qu'il vérifie si tous les fichiers dans le répertoire /lib ont changé (modifié timestamp) depuis le dernier chargement, puis déclenche un rechargement si elles changent.

Je pourrais aussi mentionner que j'ai dans ma config/application.rb
```
config.autoload_paths += %W(#{config.root}/lib)
config.autoload_paths += Dir["#{config.root}/lib/**/"]
```
Qui vient par défaut permet de s'assurer de tout mon répertoire lib est chargé.

Yays!
- Excellent fonctionne très bien si vous êtes sous-classement à partir d'un gem. J'ai utilisé cela avec de Raisin (par exemple /lib/appname/api.rb commence avec Appname::API < Grape::API) et cela fonctionne (alors que la autoload_paths fix ne marche pas).
- La signature de la méthode pour FileUpdateChecker#initialiser a un peu changé dans les Rails 3.2.x. Se débarrasser de true et tout devrait fonctionner correctement à nouveau.
- Cela a fonctionné pour moi avec le Raisin gem aussi, merci @nfm. Je n'ai cependant avoir à changer le FileUpdateChecker syntaxe légèrement à: ActiveSupport::FileUpdateChecker.new([], Dir["lib/**/*"])
- Quelqu'un peut-il éditer ce post et de vous expliquer comment recharger les fichiers à partir du répertoire lib? L'exemple actuel seulement recharge les routes (si je suis en train de lire correctement), qui ne répond pas à la question.
- Collier Avez-vous essayé? Il recharge tous les fichiers dans lib/**/*.
- peut-être pas. Je pensais que j'avais, mais en fonction de comment je l'ai formulé, peut-être que je n'ai lu que la réponse sans l'essayer? Je ne me souviens avoir pensé que ça ne marcherait pas car il est tout simplement mis à jour le autoload_paths. Imaginons qu'il fonctionne, merci.
- Cela semble fonctionner (merci!), mais pourquoi ne Rails.application.reload_routes! de rechargement de l'application?
- Dans les Rails 5.1+ ActionDispatch::Callbacks.to_prepare est dépréciée en faveur de ActiveSupport::Reloader.to_prepare
InformationsquelleAutor Patrick Hogan
21

Puisque nous parlons des Rails, le plus simple est de 'besoin' de votre lib/* .rb fichiers à l'aide de 'require_dependency'. Tant que le contrôleur/helper/etc (.rb fichiers dans le dossier app/) utilise require_dependency au lieu de juste besoin de recharger les œuvres, sans le besoin de faire quelque chose de funky.

Avant que je suis allé vers le bas de la piste, la seule solution qui a fonctionné a été l'une sur hemju.com, mais je n'ai vraiment pas envie d'avoir à pirater le ApplicationController pour Dev vitesse.
- Cela semble avoir fonctionné pour moi aussi. Trop mauvais, il ne peut pas travailler avec une plaine exiger que...
- Fonctionne très bien avec des Rails 3.2.6. C'est la meilleure et la plus propre pour répondre définitivement.
InformationsquelleAutor Paul Saladna
13

Vous devez ajouter
```
config.autoload_paths += %W(#{config.root}/lib)
```
à votre classe d'Application dans config/application.rb

https://rails.lighthouseapp.com/projects/8994/tickets/5218-rails-3-rc-does-not-autoload-from-lib
- C'est probablement mieux de le mettre dans le développement.rb
- Cela permet à mes fichiers dans lib être chargé (chargé lorsque vous accédez à la constante du même nom), mais ne semble pas aider à les amener à être reloaded sur chaque demande/lorsqu'ils sont modifiés. Je suis sur des Rails 3.2.3.
- oui, avec ce code, les fichiers dans lib sont chargées automatiquement, mais sans le recharger, MAIS quand vous mettez vos fichiers quelque part ils recharge: $:.unshift(config.root); config.autoload_paths += %w(app/models/misc) je pense à mes fichiers lib comme la logique métier, et j'ai mis de la logique métier dans mes modèles, de sorte qu'ils sont mes Modèles, mais pas de db-a persisté, et il est juste qu'ils sont dans app/models/misc et pas dans lib.
InformationsquelleAutor dishod
3

Dans RAILS 3, voici le secret de la sauce à l'auto-recharger les fichiers lib. Le code ci-dessous est un peu exagéré, pour l'exemple, mais c'est ce que j'ai fait pour le faire fonctionner. Vous pouvez modifier le message en YoYo#gogo et de le voir sur l'écran chaque chargement de la page. Enlever l'initialiseur, et il reste le même.

/config/initializers/lib_reload.rb (nouveau fichier)
```
ActiveSupport::Dependencies.explicitly_unloadable_constants << 'YoYo'
ActiveSupport::Dependencies.autoload_once_paths.delete(File.expand_path(File.dirname(__FILE__))+'/lib')
```
/lib/yo_yo.rb
```
class YoYo
  def gogo
    "OH HAI THERE"
  end
end
```
/app/controllers/home_controller
```
require 'yo_yo'
class HomeController < ApplicationController
  def index
    @message = YoYo.new.gogo
  end
end
```
- Je crois que dans Rails 3, il est autoload_once_paths au lieu de load_once_paths
- meilleure réponse, mais vous pouvez raccourcir Fichier.expand_path(Fichier.dirname(FICHIER))+'/lib " avec "#{Rails.racine}/lib" et aussi mettre un si les Rails.env.le développement? vérifier
InformationsquelleAutor Jesse Wolgamott

Voici ma version inspirée de @pbhogan's réponse qui recharge tous les rubis dans vos fichiers de rails /lib lors de l'un de ces fichiers est modifié.

Il a également fait taire les mises en garde pour éviter les messages concernant déjà initialisé constantes.

Fonctionne comme des Rails 3.2.8

if Rails.env.development?

  lib_ruby_files = Dir.glob(File.join("lib/**", "*.rb"))
  lib_reloader ||= ActiveSupport::FileUpdateChecker.new(lib_ruby_files) do
    lib_ruby_files.each do |lib_file|
      silence_warnings { require_dependency(lib_file) }
    end
  end

  ActionDispatch::Callbacks.to_prepare do
    lib_reloader.execute_if_updated
  end

end

InformationsquelleAutor jeremiemv

1

Mise à jour de réponse

Somme de toutes mes découvertes sur mon blog, tu ferais mieux de regarder là:
- http://lsd4coders.muheimwebdesign.ch/2012/09/how-to-develop-rails-3-1-engines-with-ease-part-i-the-engine/
- http://lsd4coders.muheimwebdesign.ch/2012/09/how-to-develop-rails-3-1-engines-with-ease-part-ii-the-gem/
Vieille réponse

Je regardai autour de moi pour trouver une solution pour ça aussi, et (à des fins d'exhaustivité et aussi à pointer les autres dans cette direction), voici ce que j'ai trouvé.

De Rails3.1, les moteurs peuvent être facilement généré par la commande rails plugin new my_plugin --full. Cela génère le squelette de un moteur.

--full signifie que le moteur sera "fusionné" droit dans le y compris l'application, de sorte que, par exemple, les contrôleurs devraient être directement accessibles que si elles ont été définies dans le y compris app. Cela permet, par exemple, vous demandez à une personne de fichier dans my_engine/app/helpers/my_helper.rb qui sera fusionné dans votre, y compris l'application app/helpers/my_helper.rb helper.

Il y a une autre option --mountable qui crée un espace de noms pour le moteur de sorte que ses contrôleurs etc. ne sera jamais entrer en collision avec l', y compris l'application de celles. Il en résulte par exemple une assistance dans my_engine/app/helpers/my_engine/my_helper.rb qui ne pas entrer en collision avec un helper app/helpers/my_helper.rb y compris dans votre application.

Maintenant la partie la plus intéressante:

Au sein de l'généré moteur de test dossier, il y a un dummy dossier qui détient une complète application Rails! Quel est-il?

Lorsque vous développez un moteur, ses fonctionnalités sont conçues pour fonctionner entièrement sur leurs propres, et il doit aussi être testé complètement sur son propre. Donc, c'est la "mauvaise" façon de développer un moteur "à l'intérieur" d'une autre application Rails (si cela intuitivement souvent sentirez lors de l'extraction des fonctionnalités existantes à partir d'une application Rails dans un moteur), et donc, théoriquement, il n'est pas nécessaire de recharger un moteur code à chaque requête pour l', y compris l'application.

Le "droit" chemin semble être le suivant: développer et tester votre moteur, comme si c'était une application Rails complète à l'aide de la dummy app! Y vous pouvez faire tout ce que vous pouvez faire dans le cas "normal" application Rails, par exemple, créer des contrôleurs, modèles, vues, etc. qui utilisent les fonctionnalités que le moteur doit fournir. Vous pouvez aussi normalement à partir d'un serveur à l'aide de rails s dans votre test/dummy répertoire et accéder à l'application d'exemple sur localhost:3000, et lors de l'exécution de vos tests, de la dummy application est automatiquement utilisée pour les tests d'intégration. Très gentil! 🙂

Vous devez faire attention où mettre vos trucs:
- Toute fonctionnalité qui est destiné à être utilisé dans une autre application Rails, va dans my_engine/app, alors que toutes les fonctionnalités qui sont nécessaires pour tester le moteur de la fonctionnalité va dans test/dummy/app.
Puis, ensuite, vous pouvez facilement charger votre moteur de votre application principale du Gemfile comme ceci: gem 'my_engine', :path => 'path/to/my_engine' ou le publier sur GitHub comme un bijou.

(Une chose intéressante (et pour revenir à ce sujet par sujet), c'est que lorsque je démarre le mannequin du serveur, puis toutes les modifications dans le moteur semble être reflétés à l'intérieur d'elle!!! Donc, en quelque sorte, il semble être possible d'inclure un moteur dans une application Rails, sans cache, il...? Je ne sais pas comment cela se passe.)

Donc, pour résumer: un moteur fournit une fonctionnalité qui peut être complètement sur son propre, donc il devrait également être développé et testé sur son propre. Puis, quand il a atteint un état stable, il peut être compris par n'importe quelle autre application qui a besoin de ses fonctionnalités.

Voici quelques ressources que je trouve très utiles:
J'espère que vous trouverez cette réponse utile. Je suis encore très nouveau pour les moteurs en général, donc si il y a le tort d'informations, s'il vous plaît dites-moi, et je vais le corriger.

InformationsquelleAutor Joshua Muheim

Ajouter à application_controller.rb ou votre contrôleur de base:

  before_filter :dev_reload if Rails.env.eql? 'development'

  def dev_reload
    # add lib files here
    ["rest_client.rb"].each do |lib_file|
      ActiveSupport::Dependencies.load_file lib_file
    end
  end

A fonctionné pour moi.

InformationsquelleAutor Haris Krajina

0

noter que dans Rails 3 "load_once_paths" devient "autoload_once_paths."

Aussi, il semble qu'il devrait être vide, sauf si vous explicitement de mettre quelque chose en elle.

InformationsquelleAutor Avram Dorfman
0

Aussi, assurez-vous que vous commentez la ligne suivante dans l'application.rb (en plus du @dishod de la solution), et assurez-vous que votre nom de module est le même que le nom de votre fichier (dans le cas contraire, rails de ne pas être capable de le trouver)
```
#Dir.glob("./lib/*.{rb}").each { |file| require file } # require each file from lib directory
```
InformationsquelleAutor vish
0

Travaillé pour les Rails 3.2.13 pour le rechargement lib à l'intérieur de la gemme d'une application:

require_dependency 'the_class'

ET

config.autoload_paths += %W(#{config.racine}/../fantasy/lib)

InformationsquelleAutor rndrfero

Vous devez vous connecter pour publier un commentaire.