I've spent some time trying to figure out why a junior couldn't deploy a fresh Rails project from a Windows machine (using Capistrano and the official bundler plugin).
Turns out, the Gemfile.lock contained Windows-only versions of all gems with native extensions, like nokogiri or bcrypt-ruby, and on Linux the gems weren't loaded into the bundle at all, without any warning. Specifically, the error message was no such file to load: bcrypt.
no such file to load: bcrypt
The only way to fix this was to check out the project on a Linux machine, run bundle install there - which added Linux versions of the gems to the lock file - and push back the changes. Then deployment worked normally from Windows.
This makes developing on a Windows machine and deploying directly to Linux impossible.
I do understand that this issue might be considered un-fixable for architectural issues, but still I consider it a biggie. This at least requires some notice in the manual.
Related: #635, #966
How does one then maintain Gemfile.lock under version control when doing cross-platform development? Do I instruct my windows-wielding teammates to never version control this file? What if they add a new gem?
I'm surprised and bummed that this doesn't have a milestone. This is very common and often painful shortcoming.
Yeah me too, any progress on that side?
May be bundler should not at least reinstall gems that are already installed for another platform. I have bcrypt-ruby, sqlite3 and mysql2 gems installed with switch --platform ruby but bundler each time reinstalls precompiled versions (which doesn't work)
I think this is a duplicate of #646.
Duplicates #646. Any further discussion should go there.