Bug 1574594 - bundle install defaults to --system
Summary: bundle install defaults to --system
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: rubygem-bundler
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Vít Ondruch
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-03 15:36 UTC by Evgeni Golov
Modified: 2019-05-03 06:09 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Ruby 14737 None None None 2018-05-04 10:39:52 UTC
Red Hat Bugzilla 1613864 None ASSIGNED Pathing of SCLs built on top rh-ruby25 are wrong and lead to broken builds 2019-05-03 06:09:06 UTC

Internal Links: 1613864

Description Evgeni Golov 2018-05-03 15:36:12 UTC
Description of problem:
Since the upgrade to F28, "bundle install" tries to install to /usr/share/gems even if the user did not pass --system.

Version-Release number of selected component (if applicable):
rubygem-bundler-1.16.1-3.fc28.noarch

How reproducible:
always

Steps to Reproduce:
1. run "bundle install" in any ruby project as a user

Actual results:
Your user account isn't allowed to install to the system RubyGems.
  You can cancel this installation and run:

      bundle install --path vendor/bundle

  to install the gems into ./vendor/bundle/, or you can enter your password
  and install the bundled gems to RubyGems using sudo.

  Password: 


Expected results:
Stuff is installed to ~/.gems

Additional info:
This worked fine in F27 and I tend to think this is a regression.

Comment 1 Evgeni Golov 2018-05-03 15:40:16 UTC
~/.gem, not ~/.gems, but that's not too relevant I guess :)

Comment 2 Vít Ondruch 2018-05-03 16:44:12 UTC
Oh my. Yes, there is was change in how RubyGems are installing the packages, which could be behind this. It seems Bundler guys are not going to respect that settings while they keeps breaking everything :( This will need some investigation ...

Comment 3 Vít Ondruch 2018-05-04 10:39:52 UTC
This is workaround:

https://wiki.archlinux.org/index.php/ruby#Bundler

Unfortunately, I really don't know if there is some proper fix. Therefore I filled upstream ticket.

Comment 4 Nat W. Garrison, Jr. 2018-06-16 22:07:33 UTC
I'm having the same problem with Fedora 28 Server, aarch64, loaded on a Raspberry Pi.  Besides the "bundle install" reporting the error, "rails new <project name>" reports the same error:

Your user account isn't allowed to install to the system RubyGems.
  You can cancel this installation and run:

      bundle install --path vendor/bundle

  to install the gems into ./vendor/bundle/, or you can enter your password
  and install the bundled gems to RubyGems using sudo.

  Password: 

I'm going to try the above fix that Vit Ondruch supplied.

Comment 5 Jun Aruga 2018-06-18 13:20:30 UTC
> Steps to Reproduce:
> 1. run "bundle install" in any ruby project as a user

About Evgeni Golov's case.
It means "run sudo bundle install" with sudo, right?

When I tried now, the outputted message was a little different.

Package versions

```
$ rpm -q ruby
ruby-2.5.1-93.fc28.x86_64

$ rpm -q rubygem-bundler
rubygem-bundler-1.16.1-3.fc28.noarch

$ cat Gemfile
source "https://rubygems.org"

gem 'minitest'
```

## "bundle install" by normal user without sudo => fails with an error.

```
[mockbuild@fc56022b8f0a483a90d046dc666d785e work]$ bundle install
Fetching gem metadata from https://rubygems.org/.............
Resolving dependencies...
Using bundler 1.16.1
Fetching minitest 5.11.3
Bundler::GemspecError: Could not read gem at /usr/share/gems/cache/minitest-5.11.3.gem. It may be
corrupted.
An error occurred while installing minitest (5.11.3), and Bundler cannot continue.
Make sure that `gem install minitest -v '5.11.3'` succeeds before bundling.

In Gemfile:
  minitest
```

## "sudo bundle install" by normal user => installed to /usr/share/gems/gems/

```
[mockbuild@fc56022b8f0a483a90d046dc666d785e work]$ sudo bundle install
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and installing your bundle as root
will break this application for all non-root users on this machine.
Fetching gem metadata from https://rubygems.org/.............
Resolving dependencies...
Using bundler 1.16.1
Using minitest 5.11.3
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

[mockbuild@fc56022b8f0a483a90d046dc666d785e work]$ bundle list
Gems included by the bundle:
  * bundler (1.16.1)
  * minitest (5.11.3)
```

## "bundle install" by root user => => installed to /usr/share/gems/gems/

```
<mock-chroot> sh-4.4# bundle install
Don't run Bundler as root. Bundler can ask for sudo if it is needed, and installing your bundle as root
will break this application for all non-root users on this machine.
Fetching gem metadata from https://rubygems.org/.............
Resolving dependencies...
Using bundler 1.16.1
Fetching minitest 5.11.3
Installing minitest 5.11.3
Bundle complete! 1 Gemfile dependency, 2 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

<mock-chroot> sh-4.4# bundle list
Gems included by the bundle:
  * bundler (1.16.1)
  * minitest (5.11.3)
```

Comment 6 Jun Aruga 2018-06-18 14:04:39 UTC
About the case of Nat W. Garrison, Jr.,

My environment.

```
$ rpm -q ruby
ruby-2.5.1-93.fc28.x86_64

$ rpm -q rubygem-bundler
rubygem-bundler-1.16.1-3.fc28.noarch

$ rpm -q rubygem-rails
rubygem-rails-5.1.5-1.fc28.noarch
```

Then after installing ruby-devel, zlib-devel, rubygem-sqlite3 and sqlite-devel RPM packages.

I can recommend you to try below way. I could was success to install by normal user without error.

```
$ rails new foo --skip-bundle
$ cd foo
$ bundle install --path vendor/bundle
```

Comment 7 Nat W. Garrison, Jr. 2018-06-18 19:22:58 UTC
Adding "export GEM_HOME=$(ruby -e 'print Gem.user_dir')" to the end of my .bashrc file fixed my problem.  Now when I do a "bundle install" or a "rails new <project name>" I receive no errors and all of my gem files are in one location, /home/<user name>/.gem/ruby/gems. Also I don't have to include any command line options when I issue the above two commands.

Comment 8 Aleksandar Kostadinov 2018-07-17 08:24:11 UTC
Using GEM_HOME as far as I see makes ruby ignore the system wide /usr/share/gems.

What I did instead of setting GEM_HOME is to

> export BUNDLE_PATH=$(ls -t -U | ruby -e 'puts Gem.user_dir')

This makes bundle install to the user global dir but still read system wide dir.

The only issue is that `gem install` puts binaries in `~/bin` while `bundle install` puts them in `$BUNDLE_PATH/bin`. But it can be remedied by setting `PATH` or linking `~/bin` to `$BUNDLE_PATH/bin`.

Comment 9 Aleksandar Kostadinov 2018-07-17 08:38:36 UTC
pls ignore my last comment

Comment 10 Jun Aruga 2018-07-17 08:50:07 UTC
Aleksandar, about the "rails new <project>", you can refer our below testing note.
There are roughly 3 use cases to do it.

Testing Ruby on Rails 5.2.0 on Fedora rawhide
https://github.com/junaruga/fedora-blog/blob/master/2018-06-20-test-for-rails-5.2.md

Comment 11 "FeRD" (Frank Dana) 2018-11-09 18:36:57 UTC
I am really not even a little amused about bundler's flagrant misappropriation of the `sudo` command, especially when it's done by default and apparently without any option for disabling the misfeature. winetricks does the same thing, and I think they're just as wrong for all the same reasons.

I have my account configured for passwordless sudo. (I know, that makes this _technically_ my fault, but it was never a problem until software decided they could  just start running sudo commands without a by-your-leave, and relying on the assumption of password challenges by sudo to provide user notification/confirmation).

Despite the fact that this was supposedly fixed in bundler two years ago ( https://github.com/bundler/bundler/pull/4956 ), running bundler from rubygem-bundler-1.16.1-3.fc28.noarch on Fedora 28 most certainly did install a ton of gems into /usr/share/gems/, without any indication from me that it should be doing that. Worse, in the case of certain gems that have native code components, they didn't even install _correctly_, meaning I was being spammed with error messages every time I ran a gem/bundler command.

The `gem` command has `gem install --user-install` to place gems in ~/.gem/ruby/, but bundler explicitly doesn't support that ( https://github.com/bundler/bundler/issues/2565 ). They say ( https://github.com/bundler/bundler/issues/5113 ) that bundler 2.0 will default to a local install dir (./.bundle/) instead, but that was 2 years ago and there's still no bundler 2.0.

I'm going to open an issue (done: https://github.com/bundler/bundler/issues/6780) asking that they simply add, or accept patches to add, a configuration option that disables sudo abuse entirely. In bundler 1.16/1.17, which actually exist and are in use today, regardless what may or may not be the behavior of the vaporware bundler 2.0.

...Actually, at this point they're talking about bundler THREE-point-oh (https://github.com/bundler/bundler/issues/6779), which is hilarious because where even is 2.0?

Comment 12 Ben Cotton 2019-05-02 19:50:07 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 13 Evgeni Golov 2019-05-03 06:09:23 UTC
This still happens in F29, I didn't try F30 yet.


Note You need to log in before you can comment on or make changes to this bug.