Skip to content

fix: ship an x86_64-linux-musl platform gem #194

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

Closed
wants to merge 1 commit into from

Conversation

flavorjones
Copy link
Member

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

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link

deivid-rodriguez commented Sep 1, 2022

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
Copy link
Member Author

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
Copy link

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
Copy link
Member Author

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
Copy link

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
Copy link

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
Copy link

woodhull commented Sep 2, 2022

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 arbythree mentioned this pull request Sep 2, 2022
@arbythree
Copy link

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
Copy link
Member Author

@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
Copy link

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

@arbythree
Copy link

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

@flavorjones
Copy link
Member Author

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
Copy link
Member Author

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.

@flavorjones flavorjones closed this Sep 8, 2022
@flavorjones flavorjones deleted the flavorjones-ship-a-musl-version branch May 1, 2024 13:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants