Add additional recovery step when running into platform related issues.

[andrewculver]

Not sure the ideal wording here, but after going on the journey recorded for all posterity in #121, I thought maybe it would make sense to add some instructions to avoid someone else suffering the same fate in the future.

[flavorjones]

I'm in favor of this change, since #121 and #117 provide evidence that multiple people are being confused by this bundler config setting.

[dixpac]

I also think this would be a useful addition

[flavorjones]

Note I've also submitted a PR to add a "troubleshooting" section to the README that informs users about this edge case: #123

[andrewculver]

@flavorjones Thanks for adding it to the docs! I think it still makes sense to have a message like what's being proposed in this PR, because folks running into this issue via rails new example-application --css=tailwind may not know about this specific Ruby Gem. Do you think we should add a link to your troubleshooting guidance in https://github.com/rails/tailwindcss-rails#check-bundle_force_ruby_platform from the error message?

[flavorjones]

@andrewculver Linking to the troubleshooting section is a good idea! Would you mind updating this PR to do that? Then we can poke DHH to merge.

[andrewculver]

@flavorjones Done!

[SampsonCrowley]

is there a possibility in the future of compatibility with a generic ruby build?

@andrewculver is it explained anywhere why this gem is required to be only platform specific and can't function as a generic ruby install with, as a tradeoff, lowered performance like for instance nokogiri does?

this basically kills generic gem vendor caching and guaranteeing all devs in an ecosystem are using the same version of all gems, and it's the only gem in the pipeline doing so. but it's such a lovely idea I'd hate to throw the baby out with the bathwater.

Sorry for necrobumping, but this seemed like the most relevant place in the chain of events to ask

EDIT: and before you shoot me directly, yes I do understand that it's a wrapper around the tailwind standalone, but is there not a way the ruby platform version could do os detection and download the correct binary?

[flavorjones]

@SampsonCrowley Thanks for asking this question. There are a few variations on packaging we could have chosen, but each has its own tradeoffs.

Generally it's good for a gem package to contain all the artifacts it needs, and not rely on an external network connection (not all systems will have access at install time for security reasons) or that relies on the remote repository being up and online and not throttling requestors. I've personally had bad experiences as a maintainer when Nokogiri relied on downloading source libraries for zlib, libxml, etc. at install time (circa 2009). Throttling in particular was very hard for users to work around and for me to help them with.

We could also have packaged all the binaries into a single universal gem, but then the gem would be quite large and that has drawbacks of its own (network costs for rubygems.org, slower installation, more diskspace taken up in an installation).

The current set of tradeoffs is: small, single-architecture rubygems with a tradeoff of requiring an extra step for a Gemfile.lock to work across multiple architectures. Generally you can do this by updating to a modern version of bundler and running bundle lock --add-platform=<platform> for each platform (dev, prod, whatever). Committing that info to the lockfile means you shouldn't need to do it again after that.

I'm not sure I understand the problem you're having when you say "kills generic gem vendor caching". If you are experiencing problems, can I ask you to open a new issue to discuss how to solve them?

[SampsonCrowley]

@flavorjones thanks for the quick reply. Before I open a new issue the general problem that people who tend to use force_ruby_platform are trying to solve is that there is zero way to bundle for other platforms in gem caching/secure install setups. In the company I'm with, we're loading and installing packages of gems from the same repo probably 200x a day on the low end, for only one single repo. So to minimize resources and potential security leakes, larger apps and apps that require higher security utilize a code-owned vendor cache. So bundler in production, for security reasons is set to only install from vendor cache. But increasingly, for alternate IT related security reasons, all dev machines are only being allowed to be OSx.

So in order to add the gems that deployments can build that are reviewed and vetted, the few of us that do have access have to drop into a docker image, and bundle again on Linux platform purely for this gem because there is no "ruby" platform option.

Not all devs completely understand what it takes to manage multiple platforms in a vendor cache and to be sure to always add Linux-target cache gems even when developing on osx, and devs who are on Linux have no way to add Darwin gems so when OSx devs pull new gems, that adds additional git churn

"ruby" platform option is cross platform, requires no additional deployment management and has the same content across platforms.

Mostly just want to note this as docs for the future, as I don't know what the solution is to the network issues you mentioned other than specifically gitignoring all Darwin gems, and that leaves a huge network overhead for development. But it would be nice to remove that management overhead one day in the future for people who do need the vendor/cache on larger multi-platform developer projects

[flavorjones]

I wonder if the bundler team would be open to considering a feature like --cache-all-platforms to help manage multiple platforms for teams like yours? This is just one native gem, there are others (sqlite3, nokogiri, rubymagick just to name a few) and I don't think we can fix this problem by shifting the burden onto each gem maintainer.