Insufficient identifier for ruby

[viraptor]

Describe the bug

When building ruby, the platform identifier does not become part of the package. That means you can end up with non-runnable packages which don't rebuild automatically.

Steps To Reproduce

Steps to reproduce the behavior:

1. Install ruby-2.7.5 and bundler on darwin-20 (or earlier) platform (check with uname -r or Gem::Platform.local)
2. Upgrade system to latest (darwin-21)
3. Attempt to use bundle exec ... in the built environment
4. Get: (in this case the system upgrade was 17 -> 21)

Your bundle only supports platforms ["arm64-darwin-21", "x86_64-darwin-19", "x86_64-darwin-20", "x86_64-darwin-21", "x86_64-linux"] but your local platform is x86_64-darwin-17. Add the current platform to the lockfile with `bundle lock --add-platform x86_64-darwin-17` and try again. (Bundler::ProductionError)

5. Trying to nix develop the project after the upgrade does not see the problem and does not rebuild the dependencies.

Expected behavior

Depending on ruby should cause an automatic rebuild, if the current ruby derivation was built on previous darwin version.

Additional context

Does this actually warrant making the ruby package ruby-2.7.5-darwin-21 that's also visible as ruby-2.7.5?

Notify maintainers

@vrthra @manveru @marsam

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

 - system: `"x86_64-darwin"`
 - host os: `Darwin 21.3.0, macOS 10.16`
 - multi-user?: `yes`
 - sandbox: `no`
 - version: `nix-env (Nix) 2.6.0`
 - channels(viraptor): `"home-manager-21.11.tar.gz"`
 - channels(root): `"nixpkgs"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs

[viraptor]

I didn't notice that before, but the binary cache contains the package built on Darwin 17 as well. It was a happy accident that it matched my upgrade path. However this means even installing Ruby on a new system gives you the wrong version.

The reproducer is shortened to: install ruby_2_7 (build rather than use binaries), check your Gem::Platform.local - it doesn't match your actual platform. (If you're on a higher system than 17)

[viraptor]

Hi @toonn I think this is something that could be a part of the larger macos tracking goals since it affects the whole Ruby environment. Not sure where to better rise it for discussion.

[toonn]

@viraptor, I mentioned it in the Status issue. Anything else you had in mind?

I think this is a good issue to go on the Darwin project board but I can't add issues there.

[amarshall]

Not stale, this still occurs as a broad problem. What I’m seeing is when using bundlerEnv where gems with the same input drv may have ./…/extensions/x86_64-darwin-21 or ./…/extensions/x86_64-darwin-22 etc. depending on the build host. I think we really need to be able to make the platform “version” part of the drv input, but I’ve no idea how to do that and not really sure if Nix exposes that at all.

[viraptor]

Sorry @toonn - totally missed that comment. Yes, that's about the summary of it - with the extra detail that the number depends on the kernel really, which is not controlled by nixpkgs and is likely going to have a mismatch with hydra, so the cached package downloads are... probably always going to be weird?

I've learned much more about nixpkgs since raising this issue and I'm not sure that's really solvable as a general case. Maybe we just need to accept that the bundling helpers should tell you "add a ruby platform, because specific darwin versions will be broken unless you're building for yourself"?