ruby-on-rails - instalar - rbenv windows
rbenv: Sobrevivir sin gemas (3)
TL; DR
- No te molestes con los conjuntos de piedras; múltiples versiones de una gema pueden ser instaladas concurrentemente.
- Cuando sea necesario, especifique qué versión ejecutar usando la notación
$ gem-based-binary _version_ args
. - Utilice
bundle exec
cuando tenga un Gemfile que especifique la versión.
gem install rails -v 3.2.13
rails _3.2.13_ new Project2
cd Project2
bundle exec rails server
ACTUALIZACIÓN: 2015-06-04
Escribí esta pregunta hace tres años. En parte, se basaba en una suposición falsa, y en parte la situación ha cambiado desde entonces. Con el agradecimiento de @indirect por su respuesta original, quiero llamar la atención sobre la respuesta más reciente (menos votada) de @ kelvin, resumida anteriormente.
Mi suposición es falsa: solo se puede instalar una única versión de una gema a la vez, de ahí la necesidad de que las gemas marquen el espacio de nombres. No es verdad. Se pueden instalar varias versiones de una gema al mismo tiempo. El más reciente se usará cuando se invoque desde una línea de comando, a menos que tenga un Gemfile que especifique las restricciones de versión e invoque el comando a través de bundle exec
, o especifique la versión como su primer argumento.
Consulte también ¿Cómo puedo llamar a una versión anterior de una gema desde la línea de comando? re: la notación de la versión de subrayado.
Pregunta original:
Tengo varios proyectos pasando con diferentes versiones de Rails. Tengo un flujo de trabajo (descrito a continuación) para crear proyectos utilizando versiones específicas de rieles y mantener los proyectos aislados entre sí. Me gustaría experimentar con otros flujos de trabajo, en particular, utilizando rbenv en lugar de RVM, pero no está claro cómo hacerlo.
PREGUNTA: ¿Cuál es la mejor práctica actual para crear múltiples proyectos de rieles, cada uno utilizando una versión diferente de rieles, al hacer uso de rbenv y bundler , en lugar de rbenv-gemset o rvm?
CASO DE USO: Tengo dos proyectos de rieles, llamados ProjectA y ProjectB. ProjectA se desarrolla utilizando una versión de rieles ("RailsA"), mientras que ProjectB usa una versión diferente ("RailsB"). ¿Cómo logro tener ambas versiones instaladas?
EL ENFOQUE DE GEMSETS: Cuando comencé con el desarrollo de Rails, utilicé RVM . Además de admitir múltiples instalaciones concurrentes de ruby, RVM admite tener múltiples conjuntos de gemas nombradas . Cada proyecto tiene su propia colección independiente de gemas (incluidos los rieles en sí) llamada gemset:
rvm gemset create RailsA
rvm gemset use RailsA
# RailsA. Note: My question is not version-specific.
gem install rails --version 3.0
rails new ProjectA
cd ProjectA
rvm --rvmrc use `rvm current`
vi Gemfile
bundle install
cd ..
## Now do the same for ProjectB
rvm gemset create RailsB
rvm gemset use RailsB
gem install rails --version 3.2
rails new ProjectB
cd ProjectB
rvm --rvmrc use `rvm current`
vi Gemfile
bundle install
Nota: La creación de las carpetas del proyecto se debe hacer (en mi humilde opinión) mediante un rails new
comando de rails new
utiliza la versión deseada de los rieles, ya que los archivos del esqueleto cambian de una versión a otra. (Tal vez debería volver a visitar esta premisa?)
EL ENFOQUE DE BUNDLER: He estado jugando con el uso de rbenv en lugar de RVM, pero no entiendo el flujo de trabajo con tanta claridad. En el archivo README.md , Sam Stephenson escribe que "rbenv no ... administra conjuntos de gemas. Bundler es una forma mejor de administrar dependencias de aplicaciones". Hay un complemento ( rbenv-gemset ) para obtener los mismos resultados que las gemas de rvm, pero Sam claramente prefiere utilizar Bundler. Desafortunadamente, no explica en detalle cómo sería el flujo de trabajo. Incluso el sitio web de Bundler no conecta explícitamente todos los puntos de cómo aislar un proyecto de otro. Varios blogs y blogs vienen al rescate, sugiriendo el siguiente archivo ~/.bundle/config
:
---
BUNDLE_PATH: vendor/bundle
(Por cierto, no estoy seguro de qué se trata el "---". Los documentos no lo mencionan y no parece marcar la diferencia).
Esto proporciona efectivamente a cada proyecto de rieles su propio gemset, almacenando las gemas en ProjectX / vendor / bundle /. De hecho, los rieles en sí mismos serán (re) instalados allí, haciendo que el proyecto sea completamente independiente del resto de mi entorno, una vez que ejecuto bundle install
.
¡Pero el elefante en la habitación es el problema del huevo y la gallina de crear la carpeta de proyectos de rieles en primer lugar! Para crear la carpeta ProjectA usando RailsA, primero necesito instalar los rieles (y sus numerosas dependencias). Pero cuando quiero crear ProjectB, debo pasar a utilizar RailsB. Sin gemas, debo hacer una actualización / degradación seria. No genial.
Una posible solución es simplemente no preocuparse por la versión de los rieles que uso para crear la carpeta ProjectX. Si luego uso Rails 3.0 para crear un proyecto 3.2, podría simplemente crear manualmente el árbol de aplicaciones / activos. Pero eso solo me molesta. ¿No hay una mejor manera?
La mayoría de las personas resuelve esto instalando la gema de los rieles primero a través de gem install rails
. Si se niega a hacerlo por algún motivo, puede optar por excluirse de la agrupación automática que Rails intenta hacer por usted. Esto funcionará completamente independientemente de su sistema de administración de ruby.
mkdir myapp
cd myapp
echo "source :rubygems" > Gemfile
echo "gem ''rails'', ''3.2.2''" >> Gemfile
bundle install --path vendor/bundle
bundle exec rails new . --skip-bundle
Cuando se le solicite, escriba "y" para reemplazar su Gemfile con el Rails predeterminado (o no, como prefiera). Luego, una vez hecho esto:
bundle install
Has terminado, y has desarrollado una nueva aplicación de rieles con la versión que elijas sin instalar la gema de rieles en rubygems.
Hay una buena publicación reciente sobre exactamente el tema de los conjuntos de joyas / bundler aquí http://rakeroutes.com/blog/how-to-use-bundler-instead-of-rvm-gemsets/ Buenos antecedentes que puede aplicar a su configuración de rbenv.
Supongamos que tiene los rieles 3.1.0 instalados, pero desea crear un nuevo proyecto utilizando los rieles 3.2.13 que no están instalados.
Digamos que quiere que el nuevo proyecto esté en ~/projects/Project2
.
gem install rails -v 3.2.13
cd ~/projects
rails _3.2.13_ new Project2
Esto creará el Gemfile
para usted, bloqueado a la versión de los rieles que especificó en la línea de comandos.
Deliberadamente omití la idea de guardar una copia separada de las gemas para el nuevo proyecto, porque eso va en contra de la filosofía de Bundler, que es tener todas las gemas instaladas en un solo lugar. Cuando ejecuta raíles, Bundler seleccionará automáticamente las versiones correctas de las gemas desde esa ubicación central. Eso significa que un proyecto puede compartir gemas en lugar de instalar una copia nueva para sí mismo. (Sin embargo, tenga en cuenta que cada versión de Ruby que instale tendrá sus propias gemas. Esto es bueno porque las extensiones nativas probablemente no funcionen en todas las versiones de Ruby).
Tienes que ser un poco más consciente, porque la mayoría de los comandos, como rake
, cargarán la versión más reciente de rake
que hayas instalado. Tendrá que ejecutar bundle exec rake ...
para asegurarse de que se cargue la versión correcta. Por lo general, ejecutaré bundle exec
para todos los comandos, excepto los rails
. Puede crear un alias para hacerlo más corto (yo uso bex
). Para automatizar esto con ejecutables gema, puede usar rbenv-binstubs , pero aún debe tener en cuenta que la ejecución de ejecutables que no sean gem como ruby
e irb
no usará automáticamente el Gemfile.
Sidenote : rails new
ejecutará bundle install
, que buscará la versión más nueva de las dependencias. Si desea que bundler intente utilizar las gemas instaladas actualmente que satisfagan los requisitos de dependencia, puede omitir la bundle install
del bundle install
con rails new --skip-bundle
, luego ejecutar bundle check
en el directorio de la aplicación.
Nota 2 : suponga que desea utilizar una versión de rubí para Project2 (por ejemplo, 2.1.8) que es diferente de la predeterminada (por ejemplo, 2.3.0). En ese caso, ejecutar la gem install
como se especifica arriba instalará las gemas en 2.3.0, lo cual es una pérdida de tiempo porque necesitarás instalar las gemas nuevamente en 2.1.8. Para resolver ese problema, puede forzar a los comandos a usar la versión preferida a través de la variable de entorno:
RBENV_VERSION=2.1.8 gem install rails -v 3.2.13
cd ~/projects
RBENV_VERSION=2.1.8 rails _3.2.13_ new Project2
echo 2.1.8 > Project2/.ruby-version
Puede usar el rbenv shell
para establecer la variable, pero solo lo recomiendo si no quiere que rbenv cambie automáticamente en base a .ruby-version
archivos .ruby-version
mientras dure ese shell. Es muy fácil olvidar que tiene la variable configurada, y cuando cede a un proyecto diferente, no usará la versión que espera.