Hi,
Comme certains ici j’imagine, je teste un peu Rails 3 depuis la bêta (et
même depuis le dernier apéro ruby, trop envie de me faire mon propre
convertisseur csv2json :-))
Voici mon problème du jour : les gems non présents dans mon Gemfile ne
semblent pas accessibles depuis une console. J’ai parcouru les release
notes
et le readme de bundler sans succès. En gros voici ce qui se passe :
% irb
irb(main):001:0> require ‘rubygems’; require ‘hpricot’
=> true
% rails console
Loading development environment (Rails 3.0.0.beta1)
irb(main):001:0> require ‘rubygems’; require ‘hpricot’
LoadError: no such file to load – hpricot
from
/home/salvor/dev/rails/rails3/activesupport/lib/active_support/dependencies.rb:167:in
`require’
…
Gem.path contient bien le répertoire où sont mes gems. Et si la gem en
question est dans mon Gemfile, ça fonctionne.
D’où plusieurs questions :
- bug or feature ?
- quelqu’un aurait un moyen de pouvoir charger des gems sans qu’ils
soient
dans le Gemfile ?
- des ressources sur bundler ou rails3 qui pourraient m’expliquer ça ?
Merci d’avance,
Jean-Baptiste
Même coup aujourd’hui seulement sur des gems avec une extension native
(comme hpricot). Vu tous les hacks de require dans ActiveSupport (qui
posent
des problèmes avec less en plus) ça ne m’étonnerait pas qu’il y ait un
bug
quelque part. Sinon ça vient peut-être de Bundler, faudrait essayer
d’utiliser hpricot avec juste activesupport 3.0.0.beta pour essayer de
voir
d’où ça vient.
–
Nicolas Mérouze / @nmerouze
http://boldr.net
Le 9 février 2010 22:35, Nicolas Mérouze [email protected] a
écrit
:
Même coup aujourd’hui seulement sur des gems avec une extension native
(comme hpricot).
Je rencontre le même problème avec Wirble aussi (sans compilation
locale).
C’est un peu la raison de ma question en fait : ça me paraitrait absurde
d’inclure dans le Gemfile d’une appli des choses qui n’ont rien à voir
(qui
sont dans mon .irbrc en l’occurence)…
Merci pour la réponse en tout cas,
Jean-Baptiste
Le 09/02/10 23:34, Jean-Baptiste B. a écrit :
n’ont rien à voir (qui sont dans mon .irbrc en l’occurence)…
Merci pour la réponse en tout cas,
Personnellement je trouve très bien que bundler te bloquer l’ajout de
gem si tu ne les as pas listé dans ton gemfile. Ca permet de vraiment
être sur facilement que tu n’as pas oublié de dépendance. Tu as ainsi
tout personne qui intervient sur ton projet qui est au courant des
dépendances.
–
Cyril M.
Le 09/02/10 21:45, Jean-Baptiste B. a écrit :
% irb
…
Gem.path contient bien le répertoire où sont mes gems. Et si la gem en
question est dans mon Gemfile, ça fonctionne.
D’où plusieurs questions :
- bug or feature ?
- quelqu’un aurait un moyen de pouvoir charger des gems sans qu’ils
soient dans le Gemfile ?
- des ressources sur bundler ou rails3 qui pourraient m’expliquer ça ?
Merci d’avance,
Pour info si tu regardes le fichier .bundle/environement.rb, tu
constateras que le LOAD_PATH est exactement ce que tu as définis dans
ton GemFile à la version près.
Donc si tu veux un méchant tout moche hack. modifie cette constante.
–
Cyril M.
Le 10 février 2010 11:51, Cyril M. [email protected] a écrit
:
Personnellement je trouve très bien que bundler te bloquer l’ajout de
gem si tu ne les as pas listé dans ton gemfile. Ca permet de vraiment
être sur facilement que tu n’as pas oublié de dépendance. Tu as ainsi
tout personne qui intervient sur ton projet qui est au courant des
dépendances.
Je suis bien d’accord pour les dépendances. Wirble sert à améliorer
les
consoles IRB (historique, colorisation, etc) ; ça n’a rien à voir avec
une
dépendance de mon appli. Et le require est dans mon .irbrc, donc en
dehors
de l’appli…
Jean-Baptiste
Le 10 février 2010 11:57, Cyril M. [email protected] a écrit
:
Pour info si tu regardes le fichier .bundle/environement.rb, tu
constateras que le LOAD_PATH est exactement ce que tu as définis dans
ton GemFile à la version près.
Donc si tu veux un méchant tout moche hack. modifie cette constante.
Je vais regarder de ce côté en attendant mieux, merci
Jean-Baptiste
Dans mon cas c’est un peu de la faute de Mongoid et de CarrierWave qui
n’ont
pas mongo_ext pour l’un et mini_magick pour l’autre dans leurs
dépendances.
Et c’est là que le débat se complique puisque ces 2 gems ne peuvent pas
avoir ces dépendances en dur.
Ce qui fait que ce système est loin d’être idéal et que faire un hack
pour
contourner c’est pas l’idéal non plus.
–
Nicolas Mérouze / @nmerouze
http://boldr.net
Le 10/02/10 12:56, Jean-Baptiste B. a écrit :
Je vais regarder de ce côté en attendant mieux, merci
Je comprend tout à fait ta problèmatique avec wirble et ca se défend.
Je t’encourage a rejoindre la mailing du projet bundler (
http://groups.google.com/group/ruby-bundler )
Tu pourras ainsi y remonter ton problème et demande un solution ou faire
une feature request.
Exemple, avoir son propre Gemfile, style .Gemfile qui n’est pas
versionné.
Cyril M.
it’s not a bug, it’s a feature.
En fait bundler != rubygems
Si le gem n’est pas indiqué dans bundler comme étant un gem devant
être chargé par rubygems, il n’est pas chargé par rubygems
Ce qu’il faut comprendre de façon sous jacente c’est que bundler est
un moyen de remplacer rubygems pas un truc à utiliser en parallèle.
On 9 fév, 21:45, Jean-Baptiste B. [email protected]
Bon en attendant d’avoir quelque chose de mieux, vous pouvez toujours
utiliser les groupes pour indiquer vos dépendances utilisées
exclusivement dans certains environnements…
cf. README de bundler : “Groups : applications may have dependencies
that are specific to certain environments, such as testing or
deployment.”
Nicolas.
2010/2/10 Renaud (Nel) Morvan [email protected]: