cocoapods: 1.5.3 -> 1.6.0

[lilyball]

Motivation for this change

Fixes #55458.
Fixes #55461.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Assured whether relevant documentation is up to date
• Fits CONTRIBUTING.md.

---

When testing ./result/bin/, there's a binary sandbox-pod that actually fails with the error

sandbox-exec: execvp() of '/nix/store/4r5mfkcgjabzc1k6qbdjbmyqa2kzvnr1-cocoapods-1.6.0/lib/ruby/gems/2.5.0/gems/cocoapods-1.6.0/bin/pod' failed: Operation not permitted

But this same error occurs with the current v1.5.3. I'm tempted to say we should stop vending sandbox-pod as a binary since it doesn't seem to work, but that's not actually related to this version update.

/cc @peterromfeldhk

[peterromfeldhk]

i still like to clean up ~/.gem on my osx :)
ill look into it tomorrow

[lilyball]

The modified update script doesn't touch ~/.gem so it shouldn't be deleting it.

[lilyball]

That said, I didn't remove the optional clean action.

[lilyball]

Oops yes I did. I forgot. Well, the point remains that the script doesn't have anything to do with ~/.gem.

[peterromfeldhk]

how about? worked fine without asking for password and also you should be sure that everything is fresh installed (and removed)

#!/usr/bin/env nix-shell
#! nix-shell -i bash -p bash ruby bundler bundix

BUNDIX_CACHE=$(mktemp -d)

rm Gemfile.lock
bundler install --path $BUNDIX_CACHE
bundix --bundle-pack-path=$BUNDIX_CACHE

rm -rf $BUNDIX_CACHE
rm -rf .bundle

[lilyball]

AFAICT there's no need to actually run bundler install, all we really need is the Gemfile.lock which is what bundler lock gives us.

The bundix README does suggest it looks in the bundler cache for the gems and falls back to fetching from remotes if it can't find the gem. I'm not sure if there's a benefit to this approach, but if so, the README suggests this should be generated via bundler package, not bundler install.

And finally, if we are going this route, we may as well just use a relative directory instead of making a temporary one. If you do use a temporary directory, at the very least you need quotes around $BUNDIX_CACHE in case the configured $TMPDIR has a space in it.

[peterromfeldhk]

ok i never looked that much into the workings of bundix i just assumed it needs the installed gems since it has it in -h
im fine with it as long as it works and does not leave some lingering state around

[peterromfeldhk]

i tried it with your suggestions and it still works fine and i can be sure that there is no lingering state in my system left over. and i also like how explicit it is :)

#!/usr/bin/env nix-shell
#! nix-shell -i bash -p bash ruby bundler bundix

BUNDIX_CACHE="$(mktemp -d)"

rm Gemfile.lock
bundler package --path "$BUNDIX_CACHE"
bundix --bundle-pack-path="$BUNDIX_CACHE"

rm -rf "$BUNDIX_CACHE"
rm -rf .bundle

[peterromfeldhk]

also first glance google for TEMPDIR and spaces it seems that it should not contain spaces... but better safe then sorry

[lilyball]

Ok I updated the update script to match your version.

[lilyball]

@peterromfeldhk Anything holding up this PR?

[peterromfeldhk]

@lilyball everything looks good to me.

[lilyball]

It's not clear to me how to get this merged. Looks like it doesn't even have the right labels yet (the manual says it should have the 8.has: package (update) label).

[Mic92]

@GrahamcOfBorg build cocoapods

[Mic92]

Thanks!

[lilyball]

Ironically, cocoapods 1.6.1 was just published 21 hours ago, so time to update again.

[lilyball]

Submitted the 1.6.1 update as #56221