2012-01-01 2 views
15

Итак, я разрабатываю Sinatra для обоих окон и Linux. Проблема в том, что я использую Thin вместо Webrick, а eventmachine для окон работает только с предварительной версией, в то время как linux использует последнюю стабильную версию. в Gemfile вы, конечно, не может включать в себя один и тот же камень с различными версиями, как так:с помощью связки для загрузки различных версий драгоценных камней для разных платформ

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

мне было интересно, если есть способ обойти это, возможно, используя один Gemfile для окон и один Gemfile для Linux, то, будет ли команда загружаться одна или другая.

Альтернативно, существует возможность, возможно, в git управлять только gemfile для двух разных платформ, возможно, через ветку только для файла (не знаю, возможно ли это из того, что я читал в ветвях git).

ответ

20

Вы можете сделать это так:

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

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

Полный список доступных платформ:

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 

Вы можете найти более подробную информацию в Gemfile(5) человека странице here (см ' Раздел «Платформы»).

Другой подход заключается в использовании RUBY_PLATFORM константу:

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

Я не видел полный список доступных значений для RUBY_PLATFORM но вы можете запустить

ruby -e 'puts RUBY_PLATFORM' 

на оба ваших платформах и увидеть разницу ,

+3

hmm, первое решение вызывает ту же ошибку, что и в gemfile. Условное заявление работает нормально. – indigo0086

+6

И второй подход недействителен, поскольку он сохраняет ту или иную версию gem в 'Gemfile.lock'. Он не может хранить оба. Таким образом, если вы подготовите 'Gemfile.lock' на машине Win32 dev, тогда разверните ее в Linux, вы получите ту же неправильную версию. Таким образом, я все еще ищу приемлемое решение. –

+1

Платформенный подход хорошо работает при условии, что для разных платформ нужны только разные (названные) драгоценные камни, возможно даже зафиксировать Gemfile.lock и сохранить его стабильным (в отличие от подхода if-else). – prusswan

3

Вы можете использовать опцию --gemfile для использования разных gemfiles для разных платформ. Смотрите документацию здесь http://gembundler.com/man/bundle-config.1.html

+0

я предполагаю: 1. Под «различного gemfiles» вы имеете в виду 'different 'Gemfile's' (не« разные файлы gem »); и 2.по '--gemfile' вы имеете в виду настройку конфигурации« gemfile »либо в переменной среды BUNDLE_GEMFILE, либо в файле' .bundle/config' (в домашних каталогах разработчиков). Таким образом, Бундлер безопасно может создавать, например, 'Gemfile-linux.lock' и' Gemfile-windows.lock'. – MarkDBlackwell

0

Вам нужно несколько версий (все с тем же именем) драгоценного камня. Поэтому, в настоящее время с Bundler, вам нужно несколько одновременных снимков блокировки «блокировки» зависимостей привязки. Это возможно, если ваши разработчики воспользуются настройкой конфигурации B. Они могут сделать это либо:

  1. Благодаря использованию переменной окружения BUNDLE_GEMFILE (в командной строке или в .bash_profile); или
  2. (возможно, менее желательно) в .bundle/config (глобально, в их домашних каталогах).

Таким образом, безопасно, Bundler может создавать (и, предположительно, автоматически использовать позже, с теми же настройками конфигурации), например. Gemfile-linux.lock и Gemfile-windows.lock.

Хотя этот базовый подход кажется работоспособным, он не очень СУХОЙ. Тем не менее, это улучшается, если, например, как Gemfile-linux и Gemfile-windows автоматически включать любую Gemfile заявления они имеют общие черты: то есть, если они включают в себя утверждение:

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

+0

Спасибо за ответ, но я не использовали Ruby в годах, но я уверен, что ответ в 2012 году был удовлетворительным. – indigo0086

Смежные вопросы