2012-01-01 23 views
15

Así que estoy desarrollando un Sinatra para Windows y Linux. El problema es que estoy usando Thin en lugar de Webrick y eventmachine para Windows solo funciona con una versión preliminar, mientras que Linux usa la última versión estable. en el Gemfile que por supuesto no se puede incluir la misma joya con diferentes versiones de este modo:utilizando el paquete para cargar diferentes versiones de gemas para diferentes plataformas

gem "eventmachine", "~> 1.0.0.beta.4.1", :group => :development_win 
gem "eventmachine", group => :development_linux 
gem "thin 

Me preguntaba si había una manera de solucionar este problema, tal vez usando una Gemfile para las ventanas y uno Gemfile para Linux, lo sería el comando para cargar uno o el otro.

Alternativamente, hay una manera de administrar Git Gef para dos plataformas diferentes, tal vez a través de una rama para el archivo (no sé si eso es posible por lo que he leído de las ramas de git).

Respuesta

20

Puede hacerlo así:

# Windows 
gem "eventmachine", "~> 1.0.0.beta.4.1", :platform => [:mswin, :mingw] 

# C Ruby (MRI) or Rubinius, but NOT Windows 
gem "eventmachine", :platform => :ruby 

Lista completa de plataformas disponibles:

ruby  C Ruby (MRI) or Rubinius, but NOT Windows 
ruby_18 ruby AND version 1.8 
ruby_19 ruby AND version 1.9 
ruby_20 ruby AND version 2.0 
mri  Same as ruby, but not Rubinius 
mri_18 mri AND version 1.8 
mri_19 mri AND version 1.9 
mri_20 mri AND version 2.0 
rbx  Same as ruby, but only Rubinius (not MRI) 
jruby  JRuby 
mswin  Windows 
mingw  Windows 'mingw32' platform (aka RubyInstaller) 
mingw_18 mingw AND version 1.8 
mingw_19 mingw AND version 1.9 
mingw_20 mingw AND version 2.0 

Puede encontrar más información en Gemfile(5) página del manual here (vea ' Sección de plataformas).

Otro enfoque es utilizar RUBY_PLATFORM constante:

if RUBY_PLATFORM =~ /win32/ 
    gem "eventmachine", "~> 1.0.0.beta.4.1" 
else 
    gem "eventmachine" 
end 

No he visto la lista completa de valores disponibles para la RUBY_PLATFORM pero se puede ejecutar

ruby -e 'puts RUBY_PLATFORM' 

en ambos sus plataformas y ver la diferencia .

+3

hmm, la primera solución arroja el mismo error acerca de tener dos gemas especificadas en el archivo gem. La declaración condicional funciona bien. – indigo0086

+6

Y el segundo enfoque no es válido, ya que almacena una u otra versión de gema en 'Gemfile.lock'. No puede almacenar ambos. Por lo tanto, si prepara el 'Gemfile.lock' en un equipo de desarrollo de Win32 y luego lo implementa en Linux, obtendrá la misma versión incorrecta. Por lo tanto, todavía estoy buscando una solución válida. –

+1

El enfoque de plataforma funciona bien siempre que solo se necesiten gemas diferentes (nombradas) para diferentes plataformas, incluso es posible confirmar Gemfile.lock y mantenerlo estable (a diferencia del enfoque if-else) – prusswan

3

Puede usar la opción --gemfile para usar diferentes gemfiles para diferentes plataformas. Consulte la documentación aquí http://gembundler.com/man/bundle-config.1.html

+0

Asumo: 1. bajo las diferentes gemfiles 'usted se refiere 'diferentes' Gemfile's '(no' diferentes archivos de gemas '); y 2.por '--gemfile' se refiere a la configuración' gemfile' en la variable de entorno 'BUNDLE_GEMFILE' o en el archivo' .bundle/config' (en los directorios de inicio de los desarrolladores). Por lo tanto, Bundler puede crear de manera segura, p. 'Gemfile-linux.lock' y' Gemfile-windows.lock'. – MarkDBlackwell

0

Necesita varias versiones (todas con el mismo nombre) de una gema. Por lo tanto, actualmente con Bundler, necesita varios archivos simultáneos de "bloqueo" de instantáneas de dependencia de Bundler. Esto es posible si sus desarrolladores hacen uso de la configuración de configuración gemfile de Bundler. Podrían hacer esto ya sea:

  1. Al hacer uso de la variable de entorno BUNDLE_GEMFILE (en la línea de comandos o en .bash_profile); o
  2. (Probablemente menos deseable) en .bundle/config (a nivel mundial, en sus directorios de inicio).

Por lo tanto, de forma segura, Bundler puede crear (y, presumiblemente, utilizarlo más tarde de forma automática, con la misma configuración), p. Gemfile-linux.lock y Gemfile-windows.lock.

Aunque este enfoque básico parece viable, no es muy SECO. Sin embargo, esta mejora si, por ejemplo, tanto Gemfile-linux y Gemfile-windows incorporan automáticamente cualquier declaraciones Gemfile que tienen en común: es decir, si incluyen la declaración:

::Kernel.eval(File.open('Gemfile-common','r'){|f| f.read},::Kernel.binding)

+0

Gracias por la respuesta, pero yo No he usado Ruby en años, pero estoy seguro de que la respuesta en 2012 fue satisfactoria. – indigo0086

Cuestiones relacionadas