Gemfile excludes windows for many gems (ex: rubocop)

[weedySeaDragon]

Using the master (v. 0.8.0) The lines like

 platform :ruby_20, :ruby_21, :ruby_22, :jruby, :rbx do

in the Gemfile are specifying platforms, not ruby versions or engines. These lines do not include any windows platforms. See http://bundler.io/man/gemfile.5.html

ruby
    C Ruby (MRI) or Rubinius, but NOT Windows
mri
    Same as ruby, but not Rubinius  (= C Ruby but not rubinius and not Windows)
rbx
    Same as ruby, but only Rubinius (not MRI) (= rubinius but not MRI and not Windows)

(Note that cygwin development is reported as MRI.)

In the Gemfile, this conditional excludes Windows

  platform :ruby_19, :ruby_20, :ruby_21, :ruby_22, :jruby, :rbx do
    gem 'rubocop', '~> 0.32.0'
  end

So the rubocop gem will not be installed on any windows platform. The same issue applies to: byebug, prybug, pry-stack_explorer, bkat, kramdown, cucumber-pro, license-finder, relish .
Are these lines supposed to be testing the ruby version or engine?

[ghost]

Are these lines supposed to be testing the ruby version or engine?

Ruby Version.

Can you send me a PR which works for you as well?

[ghost]

Please make sure, that all supported rubies are part of that PR.

[mattwynne]

It's not clear from the comments whether everyone's aware, so I'll just point out as it can cause some confusion. The Gemfile is only used when someone is hacking on Aruba with the source code cloned from Github. A regular user of Aruba will only get the dependencies specified in the gemspec.

[ghost]

I think @weedySeaDragon is hacking arubas' source code to make it run on windows (again).

[weedySeaDragon]

Exactly right, @dg-ratiodata. @mattwynne, I'm trying to get aruba to run on windows. I'm actually working on the ammeter gem, which uses aruba to run critical tests. I can run the tests on travis, but need to be really sure they also pass on windows. (It's always worth pointing out the difference between the gemspec dependencies and the purpose of the Gemfile.)
I should have a PR for this in a day or so. I have one working for windows, but need to test the other systems by doing some runs on travis.
(FYI: I've just discovered http://ci-appveyor.com -- which is like travis, but for Windows-based systems. Found out about it by reading thru some issues on the ChildProcess github repo. I'm coming up a learning curve but can share what I've learned if anyone is interested. Might be helpful to check the status of aruba on windows going forward. I'm also considering writing a cop (lint-type checker) for rubocop that would help catch typical windows problems for those that don't typically work on windows. But that would take a while for me.)
Stay tuned for a PR before long.

[maxmeyer]

I added some configuration for appveyor already. Should be part of the master branch.

[weedySeaDragon]

(Good to see the appveyor config, @maxmeyer !)

Question about the Gemfile:

The lines that are like this:

#platform :ruby_19, :ruby_20, :ruby_21, :ruby_22, :jruby, :rbx do

that have :jruby and :rbx -- is the intention:
(1) that those gems are to be included for all versions of Jruby and all versions of Rubinius (rbx)? Or
(2) the intent is that the gems are to be included for the versions of JRuby and Rubinius that are the same versions that were (mistakenly) implied by the ruby_... entries?

I assume it's (2), but am not sure.

[ghost]

(1) that those gems are to be included for all versions of Jruby and all versions of Rubinius (rbx)? Or

I excluded only those platforms which have troubles with a gem. Some gems make trouble in mri 1.8.7 and I was a bit lazy to search for an up to date documentation of the platform values. Just writing an incorrect one makes bundler output an up to date list but without any explanation.

[weedySeaDragon]

I excluded only those platforms which have troubles with a gem.

In the current Gemfile as it is written, since both JRuby and Rubinius are explicitly specified and thus included for every version of every gem except cucumber-pro, that means that JRuby and Rubinius have been working (passing builds) without any trouble for all of those gems, then. Yes?
(Remember that ruby_xx is a platform specification ("(MRI) or Rubinius, but NOT Windows") not a ruby version. And yes, I think that's using "ruby_..." to mean 'a particular group of ruby engines not on one particular operating system' is tremendously confusing, myself. But that's what it is.)

Given that you chose (1), then the Gemfile becomes fairly simple: it's mostly checking for versions < 1.9, <= 1.9, and > 1.9 (and those 2 gems just for Rubinius at the end). If everything is working for JRuby and Rubinius, there's no reason to specify them -- they're already included. (Except for those 2 gems just for Rubinius at the end, of course).

Is that sounding right?

[maxmeyer]

In the current Gemfile as it is written, since both JRuby and Rubinius are explicitly specified and thus included
for every version of every gem except cucumber-pro, that means that JRuby and Rubinius have been working
(passing builds) without any trouble for all of those gems, then. Yes?

Yes.

Given that you chose (1), then the Gemfile becomes fairly simple: it's mostly checking for versions < 1.9, <=
1.9, and > 1.9 (and those 2 gems just for Rubinius at the end). If everything is working for JRuby and
Rubinius, there's no reason to specify them -- they're already included. (Except for those 2 gems just for
Rubinius at the end, of course).

I choose Gate 1. ;-) Though I'm not sure if we really should use RUBY_VERSION here....

[weedySeaDragon]

FYI: The current version of the Gemfile (the one that's on master now) is working well for me.
Just a thought for the future: Another approach to dealing with the Gemfile for multiple versions, platforms, engines would be to use a template. Before each bundle install, then, some rake task would use a Gemfile template plug in the values of the current os, platform, engine (and whatever else) to create the Gemfile. That would move all of the conditional logic into the template. Not sure it would really gain anything; in fact it might be worse because that logic would be a little less obvious, being hidden one level away in a template.
I wanted to note that in case it's helpful to consider in some future work. (IMHO it's not worth doing now, and certainly not a priority given this is working.)

[maxmeyer]

Ok. If its work. I will close this one.