Add gemspec for 'x64-mingw32' platform about chef

[lamont-granquist]

can we use just use chef-mingw.gemspec? google is not helping me find docs on how the platforms get matched against the gemspec...

[lamont-granquist]

actually we came up with a policy that we didn't support gem installs of chef on windows outside of our published omnibus ruby versions (which are all 32-bit). what is your use case here, because i think this is the first time this has ever come up for us? we can revisit that policy, but supporting everyone's random gem installs is a PITA that we'd rather avoid, so we were setting out on the windows platform trying not to do that. is there some way that the omnibus installs aren't working for you, or something that you're doing that duplicates windows chefdk work (coming very soon)? if we have to support gem installs we can, but right now we don't understand how users wind up in this use case...

[tknerr]

I'm on the way of migrating to chef-dk... :-)

Here's the Gemfile that locks all my project specific dependencies. I'm currently installing them to my x64 system Ruby (not the omnibus / chef-dk embedded one):
https://github.com/tknerr/sample-application-cookbook/blob/chefdk-update/Gemfile

This works on Windows with a 32-bit Ruby (from RubyInstaller), but would fail with the 64-bit Ruby (from RubyInstaller) unless the windows specific gems are explicitly added for x64-mingw32.

Since RubyInstaller is the common way to install Ruby on Windows (and that's what you are using for omnibus / chef-dk as well I guess) it would be helpful to have both x86 and x64 supported. No randomness here, just these two platforms:

• x86-mingw32 for the 32-bit RubyInstaller Ruby
• x64-mingw32 for the 64-bit RubyInstaller Ruby

Not sure if the "advanced windows users with (maybe x64) system ruby" is really a supported use case. However, it might not hurt too much and would also be a prerequisite for 64-bit omnibus / chef-dk installs, if they ever come.

My plan in the meantime is to drop my system ruby and use the omnibus / chef-dk embedded one as the primary Ruby for all chef related stuff. Then I should be fine.

Still want to keep the Gemfile approach though (even with chef-dk) as I see no other way to version the testing related gems on a per-project basis...

[lamont-granquist]

right, but the randomness is the version of ruby that the whole potential universe of gem installers (not just you) would be installing on windows. plus bundler, plus rubygems, which have caused me a lot of rageface in the past which is solved in the omnibus package that we ship now. and its not you that we're so worried about, its windows people stumbling into rubyland doing DIY ruby installs, or re-using DIY ruby installs of ruby 1.8.7 by some sysadmin that has left the company and then winding up in our issue tracker...

so, we set out trying to avoid all that on windows...

if you can use omnibus-ruby out of chef or out of chefdk that would be vastly preferable, since it lets us keep our policy in place. i think you should still be able to use Gemfile bundles just fine, you'd just be using omnibus ruby in place of system ruby -- we definitely want to know of any issues where that does not work since having chefdk installed on a workstation and 'bundle install'ing into cookbooks that have Gemfiles is something that we clearly need to support...

[tknerr]

Agree, that's the route I'm heading to now... I'll keep it open until I can report success.

[sersut]

Overall I'm opposed to this idea.

Building x64 windows packages requires more things like ensuring all the dependencies work, all the architecture flags work as expected, modifying our CI to be able to do builds, tests and releases.

Is there a specific reason why you'd like to use 64 bit Ruby @tknerr? IMO unless there is a good reason we should defer this work.

[tknerr]

@sersut I just started off with that idea and thought it might be useful. However, I'm also fine with using the Chef-DK embedded 32-bit Ruby, that's what I'm heading to now.

[sersut]

Thanks for the note @tknerr. I'll close this issue for now until we have a good use case that requires some action items.