-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The :mswin
, :mswin64
, :mingw
, and :x64_mingw
Gemfile platform
values are soft-deprecated and aliased to :windows
#6391
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code-wise looks good to me. I think we should wait for reviews of @deivid-rodriguez @indirect and @hsbt as well before merging. 🙏
This seems good to me. I would love to improve rubygems to the point where this kind of “solution” isn’t needed, but this is an improvement on what we have now. 👍🏻 |
Hi! I was poking around in the rubygems source code for a post on native gems that I am writing, and I was reminded of this issue that I had come across earlier. rubygems/lib/rubygems/ext/builder.rb Line 29 in 0f3d7db
Would this be impacted with the change being proposed here? For my setup with RubyInstaller, I have:
Sorry for the noise if I misunderstood. |
Thank you for speaking up! If I am understanding this PR correctly, it will not change the underlying RUBY_PLATFORM, only how Bundler allows users to request gems inside the gemfile while on any Windows version of Ruby. |
@mohits what @indirect has said is correct. This PR only really affects the following in your platforms :mswin do
gem 'some_gem'
end This syntax will now bundle the gem on any mswin/mingw Windows platform. Your By way of analogy, this PR makes Gemfile |
Thanks for the clarification @johnnyshields and @indirect. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good with this, and happy to merge now.
I'd wait for the next minor or major to release it though, since this is not a bug fix nor new feature, just code cleanup, and it's technically a breaking change in case someone is somehow relying on this distinction.
@deivid-rodriguez I think this is fine to go on a minor release. It is very unlikely to affect any windows users in practice. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still have concern about mswin
and mingw
differences.
But we also don't handle platform
with various UNIX platforms like linux
, freebsd
and others. I'm okay to mix mswin
and mingw
to windows
platform.
We can reraise my concerns when anyone have new issue.
…(This is done instead of logging a deprecation warning.)
:mswin
, :mswin64
, :mingw
, and :x64_mingw
Gemfile platform
values are soft-deprecated and aliased to :windows
This is a redux of #5883. See that PR for discussion thread.
This PR makes Bundler's platform values
:mswin, :mswin64, :mingw, :x64_mingw
equivalent to the recently added:windows
. In other words, specifying any of these platform values will now bundle the specified gem on any Windows system, which is generally the desired behavior.(There is no practical use case where I would want to Bundle a gem such as Nokogiri only on
:mswin
, but not on:mingw
.)This PR does not affect how gems are built. Binary gems can/should still be built to target specific Windows architectures such as
x64-mingw-ucrt
.For comparison, this change makes Windows platforms much closer to how other platforms e.g.
:ruby
,:jruby
behave today, where a catch-all platform is used in the Gemfile rather than specifying different gems for different Mac/Linux versions.This PR also updates the manpage to indicate that users should be using
windows
in place of the others.Lastly, this PR does not add any deprecation warnings when bundling.