[Feature Request] A "prune" option, or similar.

[casperisfine]

Context

In some situations, (such as docker image building, CI caching, etc), it's desirable to minimize the bundler path footprint.

Current workaround

Here's the script we're using right now:

#!/bin/bash
set -eo pipefail

bundler_root=/tmp/bundle

echo "Cache size before pruning:"
du -sh ${bundler_root}

# Another cache; no value once all gems are installed
rm -rf ${bundler_root}/ruby/*/cache
# git dirs of installed gems are useless once we no longer have to update them
rm -rf ${bundler_root}/ruby/*/bundler/gems/*/.git

find ${bundler_root} -type f \( \
  -iname '*.a' \
  -o -iname '*.o' \
  -o -iname '*.h' \
  -o -iname '*.c' \
  -o -iname '*.d' \
  -o -iname '*.hpp' \
  -o -iname '*.cpp' \
\) -print0 | xargs -0 -n 100 rm -f

echo "Cache size after pruning:"
du -sh ${bundler_root}

And it's quite effective:

Cache size before pruning:
1.7G	/tmp/bundle
Cache size after pruning:
800M	/tmp/bundle

Proposal

This script works well, but I think that if such feature was shipped with bundler itself it would be useful for many more people.

NB: the .a/o/etc removal is probably out of scope for a generic tool, but I think the cache and .git would benefit most people without breaking anything.

[simi]

This is interesting proposal and it seems this is partially fixed by #6133. Any idea how this should work? Should it be default behaviour for frozen install for example or implemented in additional command purge?

[casperisfine]

Should it be default behaviour for frozen install

I didn't think about that, but it's interesting. We could probably assume that if BUNDLE_DEPLOYMENT=1 then you'd like to not keep caches around.

I suppose it could be its own BUNDLE_PRUNE_CACHES option, and BUNDLE_DEPLOYMENT would just enable it, this way you can still opt-out if for some reason it breaks something.

[hsbt]

@byroot I started on a prune setting for this at #9815. It is set through bundle config set prune or BUNDLE_PRUNE, and after a successful bundle install or bundle update it removes the download cache and the .git directory of every checked out git gem, which is the same set the Dockerfile of Rails repo generates removes by hand.

One constraint I want to check with you. Without an explicit bundle path Bundler installs into the system gem directory, and pruning there would delete .gem files Bundler never put in that cache, including whatever shipped with the Ruby installation.

So the setting only takes effect when BUNDLE_PATH or bundle config set path is set, and warns otherwise. Does that cover what you had in mind, or do you need it to work without a bundle path?

[byroot]

Without an explicit bundle path Bundler installs into the system gem directory, and pruning there would delete .gem files Bundler never put in that cache, including whatever shipped with the Ruby installation.

Ah that's a good catch. Honestly there's little reason to invoke prune in such instance so it's all fine if it noops.

Does that cover what you had in mind, or do you need it to work without a bundle path?

No it's perfect, it's all meant for production environments anyway. Similarly, bundle clean is a bit funky when ran in a dev environment with a shared bundle path.

[hsbt]

Thansk for your confirming. I will ship this feture at Bundler 4.1.0.

[hsbt]

Merged in #9815 and shipping in 4.1.0 as described above.