Si vous utilisez un virtualenv, vous n’avez pas envie d’installer des libs au niveau du système.
Et si vous n’êtes pas racistes, vous utilisez peut être quelques tools Ruby, comme compass.
Mais du coup, gem install compass ne marche pas, il faut soit faire un sudo, soit plonger dans les méandres de rvm. Pas glop.
Petit astuce
Virtualenv wrapper vient avec des scripts qui se déclenchent à des évenements. Typiquement, env/bin/postactivate est le script déclenché après l’activation de l’env.
Mettez dedans:
export GEM_HOME="$VIRTUAL_ENV/gems" export GEM_PATH="" export PATH=$PATH:"$GEM_HOME/bin" |
Et voilà, gem install va maintenant installer les gems dans le virtualenv.
Je suis un peu surpris, je ne suis pas développeur ruby mais j’utilise quelques fois des gems (notamment https://github.com/tjouan/zassets qui nous permet de profiter de sprockets dans un projet en php) et je n’ai ni rvm, ni besoin de faire un sudo… tout s’installe dans /Users/mickael/usr/lib/ruby/gems/ . Certes ça reste une installation “globale”, pas uniquement pour le venv, mais au moins pas besoin de sudo.
Au lieu de l’installer au niveau du système, du l’installe au niveau du user, sur ton mac où tu n’as qu’un user, ce qui revient donc à l’installer pour tous les utilisateurs. Donc de pas gérer les conflits de version. C’est pas la mort pour compass, mais pour d’autre lib, c’est dommage.
pensée fugace
”’
Tiens, je vais faire un projet en Ruby, tapons un bon rail.
Eh mais WHAT ? pas d’équivalent de virtualenvwrapper ??
”’
{% google | fu: ‘test de la solution du présent article’ %}
Aah .. Rahha .. Gwha ! Raaaahhaha … Gniiiihhhii… Aaaaaah……
{{ Cestbonça }}
Merci mec.
J’en profite de ce premier message pour saluer votre partage, en lecteur assidu que je suis.
:)