remove "BUNDLED WITH" from Gemfile.lock

[flokli]

When using bundix to package new applications, we should probably remove the "BUNDLED WITH" information from the generated Gemfile.lock.

For example, when packaging gitlab, on gitaly startup (done via bundle exec), it complains about the running version of bundler being older than the version that created the lockfile.

As we assemble the ruby environment via nix and not via bundler anyways, we can probably just remove the two lines from the Gemfile.lock

[manveru]

Sounds reasonable, do you want to make an attempt?

[flokli]

Huh, my ruby is pretty bad. Happy to try a patch, though ;-)

[alyssais]

Hmmm. Not sure this is a good idea — BUNDLED WITH is recorded so that Bundler can introduce breaking changes in its lockfiles. If we remove it, that’s not going to work.

I think we should be better at keeping Bundler up to date in Nixpkgs, but that probably requires a bit of Bundix work to make it happy with 1.x and 2.x.

[flokli]

If you call version numbers MAJOR.MINOR.PATCH, in my case it was really just the "PATCH" part being being incremented by one in the Gemfile.lock - so having bundler complain about this makes me worry about version guarantees they try to make.

IIRC, this happened while backporting the gitlab rubyenv to 19.03.

I didn't really look into how we assemble bundler environments inside nixpkgs, but how much does bundler still do dependency resolution and environment setup if we use it inside such a bundix-generated expression for it to become a problem? Won't we notice too, as it'll simply fail to start later on?

[alyssais]

If you call version numbers `MAJOR.MINOR.PATCH`, in my case it was really just the "PATCH" part being being incremented by one in the `Gemfile.lock` - so having bundler complain about this makes me worry about version guarantees they try to make.

In this case, Bundler is mostly just doing it to tell you there's a new version available.

I didn't really look into how we assemble bundler environments inside nixpkgs, but how much does bundler still do dependency resolution and environment setup if we use it inside such a bundix-generated expression for it to become a problem? Won't we notice too, as it'll simply fail to start later on?

It does it when creating the Gemfile.lock. I don't think it should be doing much that can be incompatible when you are simply using a Bundix environment. You never know, but I don't think we can stand in the way of progress over a hypothetical.

[flokli]

So what do we do here? Remove the BUNDLED WITH or keep it?

[manveru]

Let's keep this unless it causes any actual issues.

[flokli]

Ok.

[flokli]

This seems to cause actual issues - see NixOS/nixpkgs#85623 (comment).