bundle lock commands do not run hooks such as after-install-all

[joe-sharp]

Describe the problem as clearly as you can

bundle lock commands, including --update don't seem to work with any registered hooks. I could see them having a different set of hooks or simply applying the existing ones since many of the operations end up having a similar effect as bundle update and bundle install.

Did you try upgrading rubygems & bundler?

I am running the latest Bundler (2.5.7 as of this posting)

Post steps to reproduce the problem

I just looked through the source code, but if you created a simple plugin that registered an after-install-all hook you can see that it runs in most operations, but not bundle lock

Bundler::Plugin::API.hook('after-install-all') do |_deps|
  puts 'after-install-all hook run!'
end

Which command did you run?

bundle lock --add-platform
bundle lock --update=rake --conservative

What were you expecting to happen?

I expect a registered after-install-all hook to run after updating gems (and before-install-all to run before) or really even after any change to the lockfile is made. However, in the latter case, I just expect that hooks of some kind are available for plugins to use. So, I am not against additional events being added and run during bundle lock operations.

Example with bundle update:

~/dev/bundle-all 🔮❯❯❯ bundle update rake --conservative
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies...
Using rake 13.1.0 (was 13.0.6)
after-install-all hook run!

What actually happened?

The after-install-all hook doesn't run. (No other hooks do either.)

Example with bundle lock:

~/dev/bundle-all 🔮❯❯❯ bundle lock --update=rake --conservative
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies...
Writing lockfile to /Users/joesharp/dev/bundle-all/Gemfile.lock

It doesn't mention it, but this command does in fact change the Gemfile.lock to use rake 13.1.0, just like the first example using bundle update.

If not included with the output of your command, run bundle env and paste the output below

Environment

Bundler       2.5.6
  Platforms   ruby, arm64-darwin-22
Ruby          3.2.3p157 (2024-01-18 revision 52bb2ac0a6971d0391efa2275f7a66bff319087c) [arm64-darwin-22]
  Full Path   /Users/joesharp/.asdf/installs/ruby/3.2.3/bin/ruby
  Config Dir  /Users/joesharp/.asdf/installs/ruby/3.2.3/etc
RubyGems      3.4.19
  Gem Home    /Users/joesharp/.asdf/installs/ruby/3.2.3/lib/ruby/gems/3.2.0
  Gem Path    /Users/joesharp/.gem/ruby/3.2.0:/Users/joesharp/.asdf/installs/ruby/3.2.3/lib/ruby/gems/3.2.0
  User Home   /Users/joesharp
  User Path   /Users/joesharp/.gem/ruby/3.2.0
  Bin Dir     /Users/joesharp/.asdf/installs/ruby/3.2.3/bin
Tools
  Git         2.39.2 (Apple Git-143)
  RVM         not installed
  rbenv       not installed
  chruby      not installed

Bundler Build Metadata

Built At          2024-02-06
Git SHA           7ac045dcaa
Released Version  true

Bundler settings

jobs
  Set for the current user (/Users/joesharp/.bundle/config): 9

[indirect]

My understanding is that we do not fire any hooks with "install" in their name when you run bundle lock because the lock command by definition does not ever install anything.

I would expect install hooks to contain code that examines gems that have actually been installed, and expect those hooks to be run whenever someone runs bundle install later, after running bundle lock.

Can you say more about what are you trying to accomplish? Why do you want an install hook to fire when no gems have been installed?

[joe-sharp]

That makes sense. I'm certainly open to adding an additional hook for this issue. Essentially my plugin needs to trigger anytime the Gemfile.lock changes via a Bundler command.

[indirect]

What does your plugin do? What user need it is satisfying? If we know that, we can suggest approaches or add another hook if necessary.

[joe-sharp]

It ensures that changes to the lockfile are made to corresponding child lockfiles. As a basic example think of a project with a default Gemfile and Gemfile.lock but also a set in spec/fixtures. The plugin currently can ensure if I run something like bundle update --bundler that I get an updated Bundler version in both lockfiles. However all of the changes that bundle lock makes needs to be run separately for each additional lockfile. In practical use the plugin is designed for projects with generally more than several sets of Gemfiles and not always the same number or named the same.

[indirect]

Ah cool, that makes sense. That sounds like a hook more like lock-changed or something like that to me, that fires anytime any command (install, update, lock, etc) changes the lockfile. I guess if we want to have as few hooks as possible, it could even potentially be after-command and it's up to the plugin to decide if it needs to do anything. @joe-sharp what would your ideal API be for Bundler to provide to you? @deivid-rodriguez what do you think?

[deivid-rodriguez]

That makes sense to me. I like after-command. If you need to run the same command in a loop, I guess this hook would naturally pass the command that was run, so it would make things easy?

I do wonder whether managing multiple Gemfile + Gemfile.lock duples should be something builtin? I'm thinking some kind of workspaces setting and additional flag to commands (like --all, --all-workspaces, or whatever) that makes a command run in all configured workspaces. Or maybe a separate bundle workspaces [install|lock|update] command.

Just wondering since we have to change Bundler anyways to allow for this.

[indirect]

I'd love to merge in a workspaces plugin in the future, but I'd feel most comfortable if it was something we could prototype and test and get user feedback on via a plugin first.

@joe-sharp if you're interested, we could potentially work with you to announce the plugin, blog about it, link to it from the official docs, and that kind of thing once it's ready for users but you're still refining how it works.

[joe-sharp]

@indirect @deivid-rodriguez , I am getting really close to a public release of the plugin. Just FYI I had to hack around this issue: #6630 but I haven't tried just installing it as a gem and seeing what else I need to do to trigger its functionality.