RFE: A (bundler 1.x) configuration option to disable use of sudo

[ferdnyc]

I apologize for resurrecting what I'm sure is a tired subject here, and I promise that my intent is not to go back over old ground. In fact, the only reason I'm raising this is that I couldn't find any sign that it's already been discussed, somewhat to my surprise. (It's possible this simply means that I failed to find the relevant discussions, not that they weren't had.)

TL;DR

As far as the functionality of bundler 1.x, the only thing I'm asking for is a configuration option to completely disable use of sudo. It can (and should) default to off! But if it's set, bundler just never runs the sudo command. Simple as that.

Whether it outputs a message, what kind of message, how it handles not having permission... I'm not even picky, to be honest. The default/standard behavior must not change at all, unless this new configuration option is enabled.

So, my question(s) are:

1. Would the bundler developers be open to such a change, in the operation of bundler 1.16/1.17/later? (The pre-2.0 series. However legacy and soon-to-be-superseded as it may be.)
2. Would patches to add such an option/feature be considered for acceptance, if a PR were submitted implementing it? (The patches would also have to meet reasonable standards for structure and maintainability, and follow the coding style of the project, obviously.)

I mean, I don't know ruby, but I figure I can teach myself enough of it to implement this. And I'm willing to do that, if it means being able to prevent bundler performing any behind-the-scenes sudo operations, which hopefully helps to demonstrates the severity of this issue for some of us.

I appreciate the time and effort everyone involved has devoted to bundler, and hope you'll give this some consideration.

Further discussion

Running bundler 1.16.1 from the fedora repo package rubygem-bundler-1.16.1-3.fc28.noarch, I was rather surprised when it installed quite a lot of gems into /usr/share/gems/gems/, without so much as checking with me first. Even though this issue was addressed in PR rubygems/bundler#4956 over two years ago, the solution is clearly not foolproof.

Worse, it installed several gems broken, which IIUC was due to them needing to have native extensions compiled, something bundler install was not able to do successfully in the system location. Despite its use of sudo, a bundler install left me with a broken /usr/share/gems/gems/commonmarker-0.17.13/ that caused every subsequent gem/bundler command to output this message:

Ignoring commonmarker-0.17.13 because its extensions are not built. Try: gem pristine commonmarker --version 0.17.13

The suggested gem command was not successful in repairing the problem, because it didn't abuse sudo in order to further muck with /usr/share/gems/gems/. Running gem install --user-install commonmarker --version 0.17.13 was able to install a working gem in ~/.gem/ruby/gem/, and finally solved the problem. (And it's what I would've done from the start, if bundler had simply exited with the same permissions failure. But it just sudo'd its way right past the filesystem permissions.)

I have my account configured for passwordless sudo access. I will state right up front: That makes this technically my fault, and I fully accept that blame. NOPASSWORD: was never a problem when sudo was exclusively a user command. But these days it's becoming a liability. Now software developers are aware of sudo, they know that it's likely to be available on the system, and so their software makes sudo decisions on behalf of the user. (winetricks does the same thing, for one. I think they're wrong to do it, too. But I'm not here to argue that point.)

I completely accept that sudo invocation is a bundler 1.x feature, and isn't going anywhere. I also understand that bundler 2.0 (or now 3.0, which I'm already seeing talk about?) will take a different approach. But considering how extensive the changes apparently are going to be in bundler 2.0, I feel safe in saying that the 1.x series is going to be with us for quite a while longer. So, even to the extent that the statement "this won't be an issue in 2.0" is accurate, it doesn't feel to me like a reason not to address this behavior in 1.x.

And while there are existing workarounds to this issue, as bundler's install path can be reconfigured even in the 1.x series to not use system dirs, simply discovering that such a change is necessary and determining that it's possible, never mind actually figuring out the necessary commands, is far from obvious, far from clear, and not at all effectively conveyed within the bundler documentation. (Wow, that last sentence was far from good.)

As a casual bundler user, I can tell you that even poring over the locally-installed documentation doesn't really help much with this issue. There are a lot of options that involve various paths. For most of them, the documented behavior is... a bit nebulous, to be charitable. (For example, from bundle-config(1):)

path (BUNDLE_PATH): The location on disk where all gems in your
bundle will be located regardless of $GEM_HOME or $GEM_PATH values.
Bundle gems not found in this location will be installed by bundle
install. Defaults to Gem.dir. When --deployment is used, defaults
to vendor/bundle.

For casual users of bundler, if they're anything like me... I can only tell you that reading that paragraph somehow left them with less understanding of bundler's install paths than before. It certainly doesn't help explain where bundler is / has been installing things by default, or where the non-system equivalent of the default location would be, or what options the user has for other locations.... and most especially, it doesn't give you the first clue what Gem.dir even is. Which is a bit of a concern, since that collection of ASCII characters presented in that specific order means absolutely nothing to me. (Even after reading as much as I have on this, Gem.dir still doesn't mean anything to me, TBH.) A better understanding of install paths will likely only be gleaned by searching around the web, leading to discussions like the one in rubygems/bundler#2565 which help make thing a bit clearer.

My hope is that the same man page could at least feature clear documentation for a disable_sudo option, providing an obvious way to achieve an immediate goal. (Preventing bundler from forcing access to system locations, when that's not desired.) Which won't make the process of figuring out how to address the resulting permission-denied errors any easier, but it would hopefully be less urgent.

[hsbt]

Bundler 1.x is not maintaining now. If you have the same issue with Bundler 2.x, Please file as another issue. Thanks.