Comment utiliser des gemmes qui ne sont pas dans un fichier Gemfile lorsque vous travaillez avec bundler?
lorsque vous utilisez bundler avec un projet en général et des Rails en particulier, vous n'avez accès qu'aux gemmes définies dans votre Gemfile. Bien que cela soit logique, cela peut être limitatif. Surtout je trouve ça limite quand je veux utiliser un certain RSpec formateur que le reste de l'équipe n'utilise pas. Sauf si C'est dans le Gemfile, ce n'est pas accessible.
moyen de contourner cela ou je dois ajouter à Gemfile?
Mise à jour: mon problème n'était pas Bundler mais Spok. Lors de L'exécution de RSpec sans Spok Je n'ai eu aucun problème à utiliser le formatage que je voulais.
mise à jour #2: il semble que L'utilisation de Bundler soit toujours la cause du problème. La différence entre utiliser Spok et ne pas utiliser Spok, est que lors de L'exécution RSpec sans Spok, il charge le formateur avant de charger votre projet et entrer dans le Bundler "sandbox".
Avec Bundler:
$ bundle exec irb
>> require 'fivemat'
LoadError: cannot load such file -- fivemat
from (irb):1:in `require'
from (irb):1
from /Users/arikfr/.rvm/rubies/ruby-1.9.3-p194/bin/irb:16:in `<main>'
Sans Bundler:
$ irb
>> require 'fivemat'
=> true
5 réponses
je suppose qu'aucune de ces réponses n'a été choisie parce qu'elle ne résout pas bien le problème: avoir des gemmes supplémentaires que vous pouvez utiliser par défaut il n'est pas nécessaire de modifier les fichiers qui se trouvent déjà dans le dépôt. C'est, vous n'avez pas à modifier les fichiers, et vous n'avez pas à vivre avec le souvenir de ne pas vérifier vos changements locaux. Voici comment je le fais.
l'idée est essentiellement d'inverser les dépendances de Holger réponse, telle qu'il n'y a pas besoin de modifier l'partagé Gemfile. Bundler permet de spécifier quel fichier doit être utilisé comme gemfile, mais étrangement les méthodes documentées ne pas apparemment travail avec son fichier de configuration et ne sera pas résolu. Il y a une caractéristique quelque peu obscurcie de Bundler que n'importe laquelle des options de configuration peut être définie dans une variable d'environnement ou passée sur la ligne de commande. L'exécution de toutes vos commandes en tant que bundle [command] --gemfile [yourgemfile] ou BUNDLE_GEMFILE="[yourgemfile]" bundle [command] fera lire à Bundler tout ce que vous voulez gemfile. Je recommande fortement d'utiliser l'approche de la variable d'environnement, et de créer un alias ou d'exporter la variable pour votre session actuelle, d'autant plus que je n'ai pas pu utiliser le commutateur de ligne de commande avec la commande "exec".
par conséquent, je lance rspec comme ceci:BUNDLE_GEMFILE="[mygemfile]" bundle exec rspec [filename], et j'ai la première partie de cet alias bem dans mon bashrc. Fonctionne comme un charme.
ensuite, vous devez configurer votre contrôle source pour ignorer votre Gemfile, soit dans le projet .gitignore ou, pour garder le projet entièrement hygiénique sans changer sa .gitignore, à votre fichier Global ignorer personnel (qui est par défaut dans ~/.config/git/ignore et a le même format que le fichier gitignore d'un projet).
une autre chose à noter est que Bundler va créer un lockfile basé sur le nom du Gemfile. C'est très pratique, car il vous empêche d'écraser Gemfile de votre projet.verrou si c'est vérifié, mais vous devez ignorer ce nouveau fichier de verrouillage. Si votre gemfile est Foo.bar qui regarde Foo.bar.lock.
enfin, vous pouvez faire quelque chose de similaire à la suggestion de Holger dans votre Gemfile personnalisé:
source "http://rubygems.org"
gem "fivemat"
instance_eval(File.read(File.dirname(__FILE__) + "/Gemfile"))
et vous êtes bon pour aller, aussi longtemps que vous n'oubliez pas de préciser votre Gemfile.
ChiliProject nous permettre aux utilisateurs de créer un Gemfile.local qui est inclus dans le main Gemfile sur la charge. Cela permet aux utilisateurs de spécifier des gemmes supplémentaires sans avoir à changer notre Gemfile pour faciliter les mises à jour.
Pour cela, nous avons inclus le code suivant au bas de notre Gemfile.
gemfile_local = File.expand_path('Gemfile.local', __dir__)
if File.readable?(gemfile_local)
puts "Loading #{gemfile_local}..." if $DEBUG
instance_eval(File.read(gemfile_local))
end
Gemfile.local lui-même est exclu du dépôt via .gitignore.
gem 'foo' if ENV['ENABLE_FOO_GEM']
puis il suffit de définir ENABL_FOO_GEM dans votre environnement.
export ENABLE_FOO_GEM=1
le gem sera désactivé par défaut, mais facilement activé (de façon permanente) par quiconque veut l'utiliser.
Dans le cas où vous décidez de le faire (idée horrible):
Vous pouvez ajouter du code ruby à votre fichier Gemfile pour charger un~/.gemfile (ou tel) s'il existe.
quelque Chose comme:
eval(IO.read('~/.gemfile'), binding) if FileTest.exists?("~/.gemfile")
Ajouter .gitignore
Gemfile.local
Gemfile.local.lock
Ajouter au projet un Gemfile.local.taille de l'échantillon le fichier avec le contenu suivant:
# Include gems that are note meant to be part of the project but for development purposes
# That's why Gemfile.local and Gemfile.local.lock must be git-ignored
# To use these gems:
# 1. Create a "Gemfile.local" file (at same level of "Gemfile")
# 2. Prepend "BUNDLE_GEMFILE=Gemfile.local" before "bundle install" or "bundle exec rails c" and so forth.
eval_gemfile "./Gemfile"
group :development, :test do
# Suggested gems
gem "awesome_print", require:"ap"
gem "hirb"
gem "pry"
gem "pry-byebug"
gem "pry-rails"
gem "meta_request"
# My gems
gem "fivemat"
end