Je travaille sur la mise à niveau de l'une de nos applications Rails 2.3.8 vers Rails 3, et j'ai rencontré un problème gênant avec le groupeur et le déploiement. Je développe l'application sur une machine Windows, mais l'environnement de production exécute Ubuntu Linux. Maintenant, mon problème est que bundler ignore le mysql
gem dans l'environnement de production, et Passenger crache: "!!! Manque la gemme mysql. Ajoutez-la à votre Gemfile: gem 'mysql', '2.8.1'"
Voici mon Gemfile
:
# Edit this Gemfile to bundle your application's dependencies.
# This preamble is the current preamble for Rails 3 apps; edit as needed.
source 'http://rubygems.org'
gem 'Rails', '3.0.0'
gem 'net-ldap', :require => 'net/ldap'
gem 'highline', :require => 'highline/import'
gem 'mysql', '2.8.1'
gem 'net-ssh', :require => 'net/ssh'
# Bundle gems for the local environment. Make sure to
# put test-only gems in this group so their generators
# and rake tasks are available in development mode:
group :development, :test do
gem 'fakeweb', :require => 'fakeweb'
gem 'flexmock', :require => 'flexmock/test_unit'
end
Comme vous pouvez le voir, la gemme mysql
est spécifiée. Cependant, lors du déploiement, le bundler l'ignore. Pourquoi? La raison en est que Bundler génère les Gemfile.lock
Suivants (seules les parties pertinentes sont incluses):
....
mime-types (1.16)
mysql (2.8.1-x86-mingw32)
net-ldap (0.1.1)
....
Notez qu'il inclut le joyau spécifique à la plate-forme. Ce n'est évidemment PAS ce que je veux qu'il fasse, car ce joyau n'est pas adapté (et apparemment ignoré) lors de l'exécution sous Linux.
Alors, Bundler propose-t-il un moyen de résoudre ces problèmes? Ou dois-je me rappeler de changer manuellement la version de mysql gem dans le Gemfile.lock
Généré chaque fois que j'exécute l'installation de bundle sur ma machine de développement?
Merci d'avance!
Mise à jour
Il semble que l'équipe du bundler en soit consciente problème .
Il s'agit d'un problème connu dans Bundler . Les solutions de contournement sont soit:
bundle install
sans pour autant --deploy
). Bien que non recommandé en général, il s'agit d'une solution de contournement souvent utilisée jusqu'à ce que le bogue soit corrigé. Par exemple, c'est la solution recommandée offerte par Heroku.Java
). Je ne recommande pas cela sérieusement, mais je pense que cela résoudrait le problème.J'ai un problème similaire. Je voudrais pouvoir écrire quelque chose comme ça dans mon Gemfile:
platforms :Ruby do # linux
gem 'nokogiri', "1.5.0.beta.2"
end
platforms :mswin do
gem 'nokogiri', "1.4.4.1"
end
Mais, bundler me dit que je ne suis pas autorisé. Donc, ma solution de contournement, qui fonctionne dans ce cas spécifique, est de souligner une gamme de versions:
gem 'nokogiri', ">= 1.4.4.1", "<=1.5.0.beta.2"
Ce qui - pour le moment - donne la version 1.4.4.1 sur mon ordinateur Windows et 1.5.0.beta.2 sur mon ordinateur Linux. Peut-être qu'il est possible pour vous d'écrire une solution de contournement laide similaire ;-)
Nos ingénieurs chez Engine Yard ont soumis un correctif à Bundler pour résoudre ce problème et libérer les gemmes s'ils se trouvent sur une plate-forme différente. Nous avons rencontré le même problème avec de nombreuses fenêtres essayant de se déployer après avoir exécuté le didacticiel de démonstration de RailsInstaller. La meilleure solution que nous avons trouvée consiste à effectuer les opérations suivantes:
bundle install
Comme d'habitude sur votre machine de développementGemfile.lock
Et s'il y a des lignes avec -x86-mingw32
, Supprimez cette partie. bcrypt-Ruby (3.0.1-x86-mingw32)
devient bcrypt-Ruby (3.0.1)
Ruby
dans la section 'Plateformes' du Gemfile.lock
Gemfile
avec l'indicateur de plate-forme. (Je ne sais pas si cela est nécessaire mais cela ne fait pas de mal) Gemfile
: `gem 'bcrypt-Ruby', '~> 3.0',: platform => 'Ruby'bundle install
À nouveau, ce qui conservera la ligne bcrypt-Ruby (3.0.1)
et ajoutera bcrypt-Ruby (3.0.1-x86-mingw32)
à nouveau.Si vous êtes curieux au sujet du patch Bundler, vous pouvez recevoir des notifications sur https://github.com/carlhuda/bundler/pull/1451
J'espère que cela aidera quiconque cherche toujours des réponses.
Avez-vous essayé d'utiliser rvm
( lien ici )? Il peut installer des machines virtuelles et des gemmes isolés Ruby, afin que vous puissiez travailler avec un environnement plus semblable à celui que vous avez en production. Je ne sais vraiment pas si cela résoudra vos problèmes, mais c'est vaut le coup.
Quoi qu'il en soit, je sais que ce n'est pas la réponse que vous souhaitez entendre, mais à mon humble avis, Windows n'est pas la meilleure plate-forme à utiliser lors du développement dans Rails. J'ai récemment acheté un MacBook principalement pour développer des applications Rails, cela vous évite beaucoup de maux de tête. Vous pouvez également installer Linux sur votre machine de développement et l'utiliser, c'est bien mieux que d'utiliser des ports Windows ou Cygwin.
Je pense que le problème est que le joyau mysql ne découvre pas correctement les en-têtes nécessaires. Vous pouvez résoudre ce problème en passant à l'utilisation de la mysql2 gem , vous n'aurez qu'à mettre à jour vos adaptateurs de base de données dans database.yml
pour l'intégration d'ActiveRecord.
De plus, vous pouvez passer des drapeaux de construction aux gemmes d'extension C si cela est absolument nécessaire:
bundle config build.mysql --with-mysql-config=/usr/local/mysql/bin/mysql_config
.
Ne commettez pas Gemfile.lock
et vos joyaux à la production. Vous devez exécuter bundler install
à nouveau en production.
Vous pouvez faire quelque chose comme ça:
platforms :Ruby do
gem "sqlite3-Ruby", :require => "sqlite3", :group => [:development, :test]
end
platforms :jruby do
gem 'activerecord-jdbc-adapter', :require => false
gem "jdbc-sqlite3", :require => false
end
Btw, vous devez mettre votre Gemfile.lock dans le contrôle de version car de cette façon, toutes les machines exécuteront l'application avec les mêmes versions de gemmes.
Je suis tombé sur ce problème et j'ai fini par écrire un script pour cette tâche douloureuse. http://gouravtiwari.blogspot.com/2011/03/development-on-windows-deploying-to.html