Use bundler binstub if present

[ccutrer]

If bin/bundle exists, it should use that rather than the first bundle on the path. Likely the project has some customization that is important. As it stands now, I can't even override it and add bin/bundle to the path, because the action prepends the ruby bin dir to the path. And while the code has an afterSetupPathHook input that would allow me to modify the path after the action has, but before running bundle install, it's not declared in the action.yml so GitHub ignores it. Another alternative would be a new input to specifically declare which bundle binary to use (default to bundle, so that it will find it on the path).

[eregon]

If bin/bundle exists, it should use that rather than the first bundle on the path.

I'm not sure, that might use a different version of Bundler, or not accept the arguments of standard bundler, etc.

Could you show your bin/bundle and why you want this concretely?

[eregon]

Of course you can workaround this by not using bundler-cache: true.

[ccutrer]

Concrete example: openhab/openhab-jruby#408

that might use a different version of Bundler

That's kind of the point of making your own bundler binstub... to override default Bundler behavior. Once upon a time it was useful because rubygems couldn't always automatically select the correct bundler version, but that hasn't been an issue for years. Another concrete example I've had to do in another project: Docker can't remove environment variables, and an upstream image was setting BUNDLER_VERSION, and we just wanted bundler to automatically use the version specified in our lockfile. Until ruby/rubygems#6928 was merged, we had a custom binstub that removed the env var if it was an empty string.

Of course you can workaround this by not using bundler-cache: true.

True, but then I lose a significant chunk of the utility of this action! If I was that desperate, I would just fork the action and make my own local changes ;).

[eregon]

That's kind of the point of making your own bundler binstub... to override default Bundler behavior.

I think that's not reasonable to have in setup-ruby, because then any failure would likely be reported here, while the cause would be that different binstub.
setup-ruby needs to control the Bundler version for bundler-cache: true to work reliably, and it can't if it's calling an arbitrary script.

[eregon]

What's the concrete issue you have here with just using the Bundler version chosen by setup-ruby? (you can also configure that)

[ccutrer]

In this case, I need to modify bundler's behavior by injecting a gemspec that purposely does not exist on Rubygems.org - the "openhab" gem - it's used because the openhab-scripting gem should normally only be installable from within the ruby environment embedded within the openhab java runtime. But I still need to be able to run bundle install locally in order to run specs, which does the opposite - it embeds openhab inside of the jruby process. So I need to set up that faux gem ahead of bundler running.

I can understand that automatically using bin/bundler if it exists might be confusing. But what about some of my other ideas - having an explicit configuration option to specify which bundler to use, or resurrecting the after-ruby-setup hook? I could see possibly wanting to use bundle config ... or similar to set something up in CI before bundle install is called, but not have that config committed, and you can't run bundle before this action, since it's not installed.

Another potential idea - add an install-ruby option that defaults to true, and if false it skips the ruby install (and setting up path). Then one could call this action twice - once with install-ruby: true and bundler-cache: false, then do whatever you want between, then call it again with install-ruby: false and bundler-cache: true.

[eregon]

having an explicit configuration option to specify which bundler to use,

I think it's adding complexity for something extremely rarely needed, I'm trying to keep things simple, and the part about RubyGems & Bundler is already too complicated.

resurrecting the after-ruby-setup hook

It's a JavaScript hook used by setup-ruby-pkgs, it's never been an input.
There has been a related PR, #239, the reasons to reject it are there.

I could see possibly wanting to use bundle config ... or similar to set something up in CI before bundle install is called, but not have that config committed, and you can't run bundle before this action, since it's not installed.

How to deal with that is documented in the README.

Another potential idea - add an install-ruby option that defaults to true, and if false it skips the ruby install (and setting up path).

It has been mentioned before, to basically split the action in two. It adds too much complexity and maintainance overhead.

I think for your case you can not specify bundler-cache: true and if that's too slow use actions/cache (feasible if only using released Ruby versions).
Or figure out another way to create that gemspec before, or achieve that goal.

[ccutrer]

How to deal with that is documented in the README.

The readme tells me not to do the caching myself: https://github.com/ruby/setup-ruby?tab=readme-ov-file#caching-bundle-install-manually. So that's what I'm trying to avoid...