fix: ship an x86_64-linux-musl platform gem

[flavorjones]

This was not strictly necessary before now because musl platforms have
always used the generic platform gem, but recent changes in rubygems
and bundler introduced new behaviors around libc flavors, and so we're
going the extra mile here to be explicit.

See #192 for context, also see
rubygems/rubygems#5875

[flavorjones]

I'm going to wait a bit to hear back from rubygems/bundler maintainers that this is the appropriate thing to do here. Please don't merge yet.

[flavorjones]

OK, seems like the bundler fix isn't going to ship for another week.

I suspect this is low-priority for them because the majority of native platform gems can "fall back" safely to the vanilla platform (with a compilation penalty of some kind). This gem unfortunately cannot fall back, so ...

I think we should merge this, and either

1. ship a patch release of all the platforms,
2. or else run this updated rake package task against the v2.0.12 tag and ship a x86_64-linux-musl platform gem for 2.0.12.

@dhh do you have a preference? I have a slight preference for 1 and will move forward with that plan later today unless you present objections.

[deivid-rodriguez]

Hi! I'm sorry things broke. If I understand correctly, this only happens when using RubyGems 3.3.21 on Alpine, correct?

Also note that if you release a x86_64-linux-musl gem you might want to restrict the required_rubygems_version, because older versions did not support this kind of platform specific gem (it did not choose the correct variant appropriately when both linux and linux-musl are available). And you might not want to do that.

[flavorjones]

Hey @deivid-rodriguez, that's correct, I can only reproduce the issue with rubygems 3.3.21 on musl (Alpine).

I'm not confident this change actually makes things better for most people ... the issue I can most easily reproduce is the "looping" issue described at rubygems/rubygems#5871

Will this change fix that looping during bundler resolution?

Can you suggest anything else we can do to work around this until an upstream fix is released?

[deivid-rodriguez]

I think this PR should fix the looping, yes. But it may cause musl variants to get installed on glibc linux for users of old RubyGems. If the contents of the gems are exactly the same and you're just releasing them to workaround this issue, then I guess it doesn't matter although it's going to surprise people and feels wrong.

I don't have a good suggestion for you as tailwindcss-rails maintainers, but users can workaround easily by sticking to the previous RubyGems version. If you really feel this is urgent, I can try to move the release a bit earlier.

[flavorjones]

But it may cause musl variants to get installed on glibc linux for users of old RubyGems

I tested this (installed the musl gem generated from this PR's branch on a glibc system) and it works OK.

I don't feel strongly that we need to urgently address this -- we've only had one bug report, and there is a workaround ... though that may suddenly get more urgent if the default ruby:3.1-alpine image gets updated with the offending rubygems version 😆 😭 .

[deivid-rodriguez]

I tested this (installed the musl gem generated from this PR's branch on a glibc system) and it works OK.

I think it's pretty much unreliable. Sometimes it will install the correct variant, sometimes it won't.

I don't feel strongly that we need to urgently address this -- we've only had one bug report, and there is a workaround ... though that may suddenly get more urgent if the default ruby:3.1-alpine image gets updated with the offending rubygems version 😆 😭 .

They don't do that anymore, actually. The alpine image comes with the default RubyGems version that comes with each Ruby.

[deivid-rodriguez]

I tested this (installed the musl gem generated from this PR's branch on a glibc system) and it works OK.

Sorry, I misunderstood this and my previous reply makes no sense. I see now, the gem would still work ok if the RubyGems bug was triggered and the musl variant got installed on non-musl platforms. Still feels wrong to me to publish separate variants if both work equally on both platforms.

[woodhull]

for what it's worth, I also experienced this. Installing the latest rubygems fixes another problem I had, but then it causes this defect.

[arbythree]

I don't feel strongly that we need to urgently address this -- we've only had one bug report, and there is a workaround ...
Sorry to be dense but I don't understand the workaround. I'm experiencing the problem on ruby:3.0.2-alpine. Never needed to roll back rubygems version...any pointers here?

[flavorjones]

@raybradley the ruby:3.0.2-alpine image comes with a compatible version of rubygems and bundler by default:

$ docker run -it ruby:3.0.2-alpine /bin/sh
/ # gem -v
3.2.22
/ # bundler -v
Bundler version 2.2.22

Deivid's comment is saying "don't install the new version of rubygems or bundler if you're affected by this issue", not "roll back". Though, I do think he's saying that if your image installs rubygems 3.3.21 or bundler 2.3.21 and you are affected by this issue, you should update your image to not use those versions for now.

[deivid-rodriguez]

Yes, sorry if I was not clear. What @flavorjones explained is exactly what I was saying.

[arbythree]

Ok think I got it...omitted gem update bundler from Dockerfile. Thanks for the assist!

[flavorjones]

OK, new version of rubygems and bundler dropped today but there's still problems on musl platforms, I've filed a bug upstream: rubygems/rubygems#5914

[flavorjones]

Clarifying my last comment: although there is still an issue with gem install in rubygems 3.3.22, the corresponding version of bundler, 2.3.22, does work correctly and installs the x86_64-linux platform gem on musl systems.

So I don't think we need this PR or a x86_64-linux-musl platform gem. I'm going to close this without merging.