![]() If you are using frozen mode, I believe it means that you explicitly want to avoid the second issue I mentioned above, so. If you're not using frozen mode, then bundler will automatically re-resolve using the running platform if it's not already in the lockfile. This error will only happen if you are using bundler in frozen mode (with BUNDLE_FROZEN or BUNDLE_DEPLOYMENT). I believe we can improve on it but the current error message is not too bad, and allows for easily fixing the issue. ![]() Resolving for the specific running platform and recording the exact resolution in the lockfile fixes the above issues. To me this is totally unexpected, if you have a Gemfile.lock file, no third party release should be able to change the set of third party code that you run. Then when you deploy to production, foo-1.2.0-x86_64-linux will be installed because it matches the running platform more closely. Then someone pushes foo-1.2.0-x86_64-linux to, a platform specific variant for foo 1.2.0, that, for example, has a critical bug, or that was pushed by a malicious actor. You have a lockfile specifically locking foo to 1.2.0, you test it in CI and in your staging environment, and it's all good. Say you're using foo-1.2.0 in your application. Not only resolution is invalid, but the previous approach meant resolution was not actually fully locked. For example, nokogiri recently released prerelease versions meeting this condition. Without considering the specific platform for resolution, we might not get a valid set of dependencies, since new unconsidered constraints can be introduced after resolution. Resolution would be incorrect sometimes, since it can happen that for the same gem and version number, a platform specific variant can have different dependencies than the standard variant. What bundler would previously do is to resolve dependencies without considering platforms, and then at installation time, pick up platform specific variants with the same version as the resolved version if they exist. In previous bundler versions, bundler didn't consider platforms for resolution at all. Let me try to explain why we did this, and why I believe it's a good thing. Hi I've been sleeping on this issue, and I think what we have now is quite good to be honest. I'm happy to help brainstorm here or provide support if I can. For those that can be updated, it would be ideal to not have to add an extra step. Ideally, I would like to get them back to being valid as many are not maintained and will never be updated. This change in behavior with 2.2.3 means a lot of existing tutorials for deploying Ruby apps now no longer work. Future musingsĪs a feature of bundler, I want to be able to either have bundler default to linux as a secondary platform or have some way of specifying it globally. Then customers will be unblocked in the short term (provided I don't have to rollback due to a yet-to-be-found regression). Remote: Bundler Output: Your bundle only supports platforms but your local platform Remote: -add-platform x86_64-linux` and try again. ![]() Add the current platform to the lockfile with `bundle lock Remote: Your bundle only supports platforms but your local platform Remote: Running: BUNDLE_WITHOUT='development:test' BUNDLE_PATH=vendor/bundle BUNDLE_BIN=vendor/bundle/bin BUNDLE_DEPLOYMENT=1 bundle install -j4 Remote: -> Installing dependencies using bundler 2.2.3
0 Comments
Leave a Reply. |