Why "bundler install" always ask me my root password?

[slainer68]

Hi,

I'm using latest bundler version (1.0b9 on Ubuntu) and bundler always
ask me my root password when I run "bundle install" with prompt "Enter
your password to install the bundled RubyGems to your system". Why ?

I thought that the main feature of bundler is to install the required
gem to ~/.bundler and therefore not having to install each gem as a
superuser ?

Thanks,

Nicolas

[Tom Ward]

I think the latest versions of bundler install gems to the system gem
path by default. However you can change this behaviour by doing:

bundler install <destination>

Tom

> --
> You received this message because you are subscribed to the Google Groups "ruby-bundler" group.
> To post to this group, send email to ruby-b...@googlegroups.com.
> To unsubscribe from this group, send email to ruby-bundler...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/ruby-bundler?hl=en.
>
>

[slainer68]

On 22 juil, 15:03, Tom Ward <t...@popdog.net> wrote:
> I think the latest versions of bundler install gems to the system gem
> path by default.

Even if that's the new default, why is it asking my password even if
there is no new gem to install? It's annoying...

[slainer68]

I've opened an issue.

http://github.com/carlhuda/bundler/issues/issue/484

[Steve Eley]

Joining the list and resurrecting this thread to add my vehement
objection to this design decision. Many admins and developers believe
it's very bad practice for application deployments to _ever_ touch
root. Capistrano and Vlad recipes are often crafted to ensure that
everything happens in userspace -- and it's common to set environments
up so that developers can push deployments without knowing the root
password.

The default 'bundle install' in 1.0rc destroys this security
practice. Worse, it destroys it for no good reason. What was wrong
with the user-level .bundle directory? Was anyone raising issues that
redundant .gem files on a multi-user system were making them run out
of disk space? By changing the default to system-level gems in order
to save those megabytes, you've likely broken every automated
deployment script that included 'bundle install.' Is it worth it?
Was the purpose of Bundler to save disk space, or to make automated
application deployment easier?

Yes, I know I can override the bundle path -- and I did, after
spending way too much time on Github issues and trying to navigate the
fragmented and structureless documentation at rubygems.org. But I
*shouldn't have to.* The default should be one that never requires
root, and the system-level bundle path that requires root access
should be the command-line option. I believe this reflects real-world
application deployments much better, and will result in fewer
failures.

If you disagree with my argument, then at the very least I strongly
suggest some elegant exception handling to fall back to a local bundle
path without hanging on a password prompt. (In my case, using Vlad, I
didn't even get prompted -- it simply failed out with the "sudo: no
tty present and no askpass program specified" error that's been
reported by others.)

Thank you for your time.


Have Fun,
- Steve Eley

[Adam Williams]

Thank you, Steve, for this email. I expect it to be helpful when I move from 0.9.26 to 1.0. Unless, of course, they change things to work as you so well (as I understand, at least) suggest :)

[Steve Eley]

On Jul 28, 10:42 am, Steve Eley <sfe...@gmail.com> wrote:
>
> Yes, I know I can override the bundle path -- and I did, after
> spending way too much time on Github issues and trying to navigate the
> fragmented and structureless documentation at rubygems.org.  

Sorry, correction: I meant the documentation at gembundler.org, of
course. I'm embarrassed that I missed that error even on a re-read
before sending.

[Stephen Eley]

On Wed, Jul 28, 2010 at 11:07 AM, Steve Eley <sfe...@gmail.com> wrote:
>
> Sorry, correction: I meant the documentation at gembundler.org, of
> course.

Argh! gembundler.com!

Sorry again. I think I'm just going to go back to bed now. And stay
there until Rails 4 comes out.

--
Have Fun,
   Steve Eley (sfe...@gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

[Chad Woolley]

On Wed, Jul 28, 2010 at 7:42 AM, Steve Eley <sfe...@gmail.com> wrote:
> On Jul 22, 9:24 am, slainer68 <slaine...@gmail.com> wrote:
>> On 22 juil, 15:03, Tom Ward <t...@popdog.net> wrote:
>>
>> > I think the latest versions of bundler install gems to the system gem
>> > path by default.
>>
>> Even if that's the new default, why is it asking my password even if
>> there is no new gem to install? It's annoying...
>
> Joining the list and resurrecting this thread to add my vehement
> objection to this design decision.  Many admins and developers believe
> it's very bad practice for application deployments to _ever_ touch
> root.  Capistrano and Vlad recipes are often crafted to ensure that
> everything happens in userspace -- and it's common to set environments
> up so that developers can push deployments without knowing the root
> password.
>
> The default 'bundle install' in 1.0rc destroys this security
> practice.  Worse, it destroys it for no good reason.  What was wrong
> with the user-level .bundle directory?  Was anyone raising issues that
> redundant .gem files on a multi-user system were making them run out
> of disk space?  By changing the default to system-level gems in order
> to save those megabytes, you've likely broken every automated
> deployment script that included 'bundle install.'  Is it worth it?
> Was the purpose of Bundler to save disk space, or to make automated
> application deployment easier?

I' m also curious to get an official position on what drove this
decision - and ideally get it documented on gembundler.com

The main reason I can think of is to follow the Principle of Least
Surprise - if Bundler installs a gem, I expect it to be in my default
gem directory. It's the default, right?

I totally understand and agree with Steve's objections to installing
things as root, but I believe the 'root' cause (hehe) is that RubyGems
makes the GEM_HOME root-owned by default. I like to fix this by using
RVM, which lets you have a non-root-owned GEM_HOME (and as many
GEM_HOMEs as you want via gemsets). If you don't want to use RVM, you
can achieve the same thing by overriding the GEM_HOME for your
system-wide ruby installation to be non-root owned (e.g. have write
access by a developer group), or even have Ruby totally installed as
user-owned (although I don't know why you wouldn't just use RVM if you
are going to this much trouble).

Does this change your perspective at all, Steve?

Thanks,
-- Chad

[Andre Arko]

On Jul 28, 2010, at 8:58 AM, Chad Woolley wrote:
> I' m also curious to get an official position on what drove this
> decision - and ideally get it documented on gembundler.com

I suggest reading Yehuda's blog post about 1.0rc, here:

http://yehudakatz.com/2010/07/26/whats-new-in-bundler-1-0-0-rc-1/

It discusses both the change to default to system gems and deploying without root. The tl;dr version is that the new defaults are optimized for developing locally, and `bundle install vendor/bundle` is optimized for deployments, and never requires root permissions.

— Andre

[Chad Woolley]

On Wed, Jul 28, 2010 at 9:35 AM, Andre Arko <an...@arko.net> wrote:
> On Jul 28, 2010, at 8:58 AM, Chad Woolley wrote:
>> I' m also curious to get an official position on what drove this
>> decision - and ideally get it documented on gembundler.com
>
> I suggest reading Yehuda's blog post about 1.0rc, here:
>
> http://yehudakatz.com/2010/07/26/whats-new-in-bundler-1-0-0-rc-1/

Thanks Andre. I still think it would be a great idea to have a "best
practices" ("philosophy?" "tenets?" "dogma?" "pedantisms?") section
on gembundler.com to collect all of these justifications and pearls of
wisdom into one place. Otherwise you'll continue to get questions
like this on the mailing list (in fact I've got one to post right now)

Thanks,
-- Chad

[Andre Arko]

On Jul 28, 2010, at 9:44 AM, Chad Woolley wrote:

> I still think it would be a great idea to have a "best
> practices" ("philosophy?" "tenets?" "dogma?" "pedantisms?") section
> on gembundler.com to collect all of these justifications and pearls of
> wisdom into one place.

I agree, and it's something that we'll be adding as time allows. We needed to write the code and make sure it worked, first. :)

— Andre

[Stephen Eley]

On Wed, Jul 28, 2010 at 11:58 AM, Chad Woolley <thewoo...@gmail.com> wrote:
>
> Does this change your perspective at all, Steve?

No. I know all of that, and I do use RVM in my development
environment. Development's not the problem. The Principle of Least
Surprise violation here is in *deployment.* When you're trying to get
a production machine up and running to stage your application, you
want as little weirdness as possible. You want things you can
automate with stock recipes in Puppet or Chef, or if it's a manual
process, you want a *simple* checklist where the defaults make sense
and don't require blog-documented tweaks for the mainstream use case.

From the perspective of a system administrator who wants controllable
environments, Ruby's already weird enough. Having to set environment
variables to avoid root access because your *gem streamlining
framework* demands it is asking for an argument. And RVM? I love RVM
on my machine, but trying to explain it to a sysadmin as a necessity
in production -- much less make it repeatable and automated -- is
liable to make someone's head explode.

My frustration here is that it's unnecessary. It's *adding* a root
constraint where none existed before! Ruby itself doesn't force sudo.
If you're using a stock Ruby and you install a gem without sudo, it
puts it in ~/.gem and everything still works. As of 1.0rc, Ruby's
basic defaults are more flexible than Bundler's.

Isn't that backwards? Wasn't Bundler built to make it *less*
important where your gems are located? Wasn't it supposed to make
Ruby apps easier to deploy? Should Bundler assume RVM as a
requirement -- or should it be making RVM's own convoluted gem
management facilities irrelevant?

In conclusion: no. I do not believe that "Bundler IS easier! As long
as you use RVM, override your environment, or specify a local
directory on the command line (as documented on Yehuda's blog)" is in
keeping with the Principle of Least Surprise.

[Stephen Eley]

On Wed, Jul 28, 2010 at 12:35 PM, Andre Arko <an...@arko.net> wrote:
>
> I suggest reading Yehuda's blog post about 1.0rc, here:
> http://yehudakatz.com/2010/07/26/whats-new-in-bundler-1-0-0-rc-1/
>
> It discusses both the change to default to system gems and deploying without root. The tl;dr version is that the new defaults are optimized for developing locally, and `bundle install vendor/bundle` is optimized for deployments, and never requires root permissions.

I read it. I don't think it offers explanation on the reasoning
process that justifies the change. It doesn't explain what the pain
point was.

Why are the new defaults optimized for developing locally? Why is
that the priority over deployment? More to the point, why is
deployment now expected to follow a *different use pattern* than local
development?

The slogan underneath the masthead on gembundler.org says:

"Bundler manages an application's dependencies through its entire life
across many machines systematically and repeatably."

Please explain how a change that requires either overriding Bundler's
'local development' assumptions *or* prompting for the manual entry of
a root password on deployment helps make my life easier across many
machines, "systematically and repeatably."

I'm not trying to be an ass. I'm not picking a fight just to be
unpleasant. I'm very sincere about this. A change was made that's
made using Bundler for its intended purpose harder and more confusing.
If the change brings practical benefits that justify the cost of user
education and altered usage, those benefits have not been clearly
communicated.

Going into release with these defaults would be a bad idea. Bundler
already has a mixed reputation in the community due to early adopter
pains and unclear expectations. A 1.0 release is an opportunity to
fix that and demonstrate a mature, clean, simple gem management
solution that works well across a wide spectrum of work patterns.
*Or* you could break a large number of existing deployment recipes and
make people start seeing root password prompts where they didn't see
them before.

Is it worth it?

Again, thanks for listening.

[Yehuda Katz]

Steve,

I am going to respond to your emails in much more detail later, but first I'd like to add one thing to what has already been said.

We agree that it's unacceptable for our development-time friendly defaults to cause problems in production. Further, we agree that it's unacceptable for you to have to make use of Google to figure out what the right incantations to give bundler for good deployment practices.

As a result, we are going to add a --production flag to bundler 1.0.0 final that encapsulates all of the best deployment practices. This will include installing to the local application, rather than wherever $GEM_HOME happens to be.

Again, I'll respond to more of your specific points later today.

Yehuda Katz
Architect | Engine Yard
(ph) 718.877.1325

--

[Yehuda Katz]

Yehuda Katz
Architect | Engine Yard
(ph) 718.877.1325

On Wed, Jul 28, 2010 at 7:42 AM, Steve Eley <sfe...@gmail.com> wrote:

On Jul 22, 9:24 am, slainer68 <slaine...@gmail.com> wrote:
> On 22 juil, 15:03, Tom Ward <t...@popdog.net> wrote:
>
> > I think the latest versions of bundler install gems to the system gem
> > path by default.
>
> Even if that's the new default, why is it asking my password even if
> there is no new gem to install? It's annoying...

Joining the list and resurrecting this thread to add my vehement
objection to this design decision.  Many admins and developers believe
it's very bad practice for application deployments to _ever_ touch
root.  Capistrano and Vlad recipes are often crafted to ensure that
everything happens in userspace -- and it's common to set environments
up so that developers can push deployments without knowing the root
password.

Absolutely. The current default is a development-time default, made because users were (and continue to be) confused when bundle install did not install gems into a location visible from `gem list`.

It is not the appropriate default for production mode, and we will add a --production flag before 1.0 that (among other things) defaults to installing gems to the application's vendor directory, rather than attempting to install them to the system's gem repository.

 

The default 'bundle install' in 1.0rc destroys this security
practice.  Worse, it destroys it for no good reason.  What was wrong
with the user-level .bundle directory?  Was anyone raising issues that
redundant .gem files on a multi-user system were making them run out
of disk space?  By changing the default to system-level gems in order
to save those megabytes, you've likely broken every automated
deployment script that included 'bundle install.'  Is it worth it?
Was the purpose of Bundler to save disk space, or to make automated
application deployment easier?

We absolutely did not make this decision in order to save disk space. Instead, it was a response to a large number of confused users who expected bundle install to install gems to their system. This was further exacerbated when we started to use gems already installed in the system if they were available. We did this both for install-time performance (if you already have all the needed gems on your system, why do the remote fetching dance, which can take quite some time) as well as to enable usage of gems that are difficult to install (like the MySQL gem).

That said, all of these reasons are inapplicable to an automated deployment environment.

 

Yes, I know I can override the bundle path -- and I did, after
spending way too much time on Github issues and trying to navigate the
fragmented and structureless documentation at rubygems.org.  But I
*shouldn't have to.*  The default should be one that never requires
root, and the system-level bundle path that requires root access
should be the command-line option.  I believe this reflects real-world
application deployments much better, and will result in fewer
failures.

Correct. While we have made bundler's operation somewhat flexible and configurable, "do the right thing for deployment" should not require incantations and reading through the manual. In my opinion, you should only need to read the manual if you are using an advanced feature (like groups, outside the context of Rails, which manages groups for you).

 

If you disagree with my argument, then at the very least I strongly
suggest some elegant exception handling to fall back to a local bundle
path without hanging on a password prompt.  (In my case, using Vlad, I
didn't even get prompted -- it simply failed out with the "sudo: no
tty present and no askpass program specified" error that's been
reported by others.)

We can absolutely check for tty? and tell the user to use the --production flag (or, for the moment, bundle install vendor --disable-shared-gems). That said, once this whole thing is down to "run bundle install in development and bundle install --production when deploying", I think we'll be in a much better position.

All of the feedback we've been getting on user experience is what is helping us figure out the requirements for things like the --production flag. Keep it coming.

 

Thank you for your time.


Have Fun,
 - Steve Eley

[Stephen Eley]

On Wed, Jul 28, 2010 at 4:26 PM, Yehuda Katz <wyc...@gmail.com> wrote:
>
> Absolutely. The current default is a development-time default, made because
> users were (and continue to be) confused when bundle install did not install
> gems into a location visible from `gem list`.

Correct me if I'm wrong, but couldn't that be resolved without root by
using ~/.gem as the bundle path? (Or traversing the gem path on
exceptions to find a writable one, or offer to write the bundle path
to .gemrc, or override 'gem list' with a rubygems plugin, or etc.
etc.)

I see your logic, and I appreciate the detailed and patient response.
It still feels like insufficient reason for a deployment-breaking
change, however. It's going in the wrong direction. Bundler's
original appeal to me was its portability; but it's now *less*
portable and scriptable in its default state than 'gem' by itself.
(Which may emit warnings if it has to fall back to ~/.gem, but doesn't
try to force user interaction with sudo.)

> We can absolutely check for tty? and tell the user to use the --production
> flag (or, for the moment, bundle install vendor --disable-shared-gems). That
> said, once this whole thing is down to "run bundle install in development
> and bundle install --production when deploying", I think we'll be in a much
> better position.

It would certainly help, yes. I continue to disagree with this
decision -- but I do recognize it as a thoughtful and carefully
planned one. My concerns stand, but I _was_ able to get my own
deployment working, and time will tell whether my bigger-picture
worries are valid or an overreaction. Thanks once again.

[Wincent Colaiuta]

So users were confused that Bundler wasn't installing to a location
visible to "gem list", but one thing that has struck me as incongruous
is that with "gem" if you want to do a root privileges install you
have to type "sudo gem install", it doesn't invoke sudo for you
itself.

I'd rather see Bundler fail with an error message if it can't write to
the destination directory, perhaps suggesting that the user perform
"sudo bundle install", rather than automatically invoking sudo itself.
I guess the idea is to make it easy for the user, but it is strikingly
different from how almost every other command line tool works (can't
think of any examples right now which invoke sudo by themselves).

This would also be helpful in a production environment where people
might not want (or be able) to interact with Bundler during the
install. With an appropriate entry in /etc/sudoers you can allow "sudo
bundle install" to be run by a particular user without having to
supply a password.

In any case, I've always set BUNDLE_PATH to a writable location
(APP_ROOT/.bundle) actually, so I've never had to use sudo, and I
imagine I'll keep doing it in exactly this way.

Cheers,
Wincent

[Ed Howland]

I agree with Wincent's comments here. It occurs to me that users (at
least me), would not expect Bundler to act the same as gem install,
since there are two different use cases. Bundler seems app specific to
me since there is a Gemfile in app root. Whereas, gem installs gems
that are either system wide (sudo gem install), or local to a user
(~gem) or via rvm. These are typically the latest gems and used across
many development projects. (nokogiri, net-smtp, etc.)

The use case for Bundler, it seems to me, is towards the deployment
end of the project's lifecycle. You want to lock down the dependent
gem versions so there are no surprises at actual deployment time or
during final integration testing. I think that I won't need Bundler
till I am well enough along that I am satisfied the existing gems, and
the quantity of them, are working for me.

Or do I have this wrong? Should I start my project with bundle init,
and keep updating it as I install/need gems?

Also, this reliance on the command line options (bundle install [opts]
path) and environment variables, while ok, should be augmented by
settings in the Gemfile. That way a 'bundle install' command would be
all you need to do. This also make the app self-documenting:

Gemfile:

set :bundle_path, 'vendor'
set :disable_shared_gems, true
set :default, :development # override with --production

gem 'nokogiri'
etc.

Now, new checkouts of the project just need to run 'bundle install'.
And my deploy.rb hust does bundle install --production. This is the
Principle of Least surprise. I was actually surprsied that bundler
installed gems in ~/bundle, at first.

Please remove the auto sudo from bundle install. Either fail
gracefully, or let the no permissions exception bubble up. Thanks.

Cheers,
Ed

Ed Howland
http://greenprogrammer.wordpress.com
http://twitter.com/ed_howland

[Jean-Baptiste BARTH]

Hi,

Wincent Colaiuta <w...@wincent.com> :

> I guess the idea is to make it easy for the user, but it is strikingly
> different from how almost every other command line tool works (can't
> think of any examples right now which invoke sudo by themselves).

I have one : wajig is an apt-get/dpkg/service front-end on debian like systems. But it's not necessarily an example to follow. I used to love it, but now I think this kind of behavior should be either optional, or left under my responsibility in my shell aliases.

--
Jean-Baptiste

[Carl Lerche]

When I use bundler, I never have to enter the sudo password. When I am
in development, I use rvm, so all my gems are installed a user owned
directory. When I deploy, I use `bundle install ./vendor` and, again,
everything gets installed to a user owned directory.

The reason why bundler calls sudo itself as opposed to doing sudo
bundle install is that then, all the files that bundler writes during
install (Gemfile.lock, .bundle/config, etc...) would get owned by the
super user, and that would be a problem (obviously). If somebody can
explain how to work around this issue, then I would be happy to stop
bundler from calling sudo itself.

As for why bundler stopped installing to ~/.bundler by default when
$GEM_HOME was owned by the super user, well, that behavior just pissed
me off personally. It also was very confusing to people just getting
started with ruby, rails, and bundler, and that actually should be as
smooth of an experience as possible.

As a last note: Bundler is optimized for development time as opposed
to deployment because, as developers, we spend most of our time in
development, and deployment is scripted. I think we all can manage
adding a 8 more characters to our deployment scripts.

Later,
-carl

[Chad Woolley]

On Wed, Jul 28, 2010 at 11:34 AM, Stephen Eley <sfe...@gmail.com> wrote:

> My frustration here is that it's unnecessary.  It's *adding* a root
> constraint where none existed before!  Ruby itself doesn't force sudo.
>  If you're using a stock Ruby and you install a gem without sudo, it
> puts it in ~/.gem and everything still works.  As of 1.0rc, Ruby's
> basic defaults are more flexible than Bundler's.

I don't believe this is true. Going forward, RubyGems will force you
to pass '--user-install' if you want to install to ~/.gem, and will
error if you try to install to a root-owned GEM_HOME without
specifying it. In other words, '--no-user-install' is the default
(even though 1.3.7 gem install --help doesn't list it - this is a doc
bug).

So, stock RubyGems going forward DOES force sudo by default unless you
pass an option.

The point being - it isn't too crazy to expect non-development bundler
usage to require a special flag '--production', since you'd have to
pass something extra to 'gem install' in any case (either prefix with
sudo, or pass --user-install). And if the current behavior is what
the Bundler devs have found to cause the minimal confusion and
complaints in development, it's probably best to keep it that way :)

-- Chad

[Yehuda Katz]

Yehuda Katz
Architect | Engine Yard
(ph) 718.877.1325

On Wed, Jul 28, 2010 at 3:39 PM, Stephen Eley <sfe...@gmail.com> wrote:

On Wed, Jul 28, 2010 at 4:26 PM, Yehuda Katz <wyc...@gmail.com> wrote:
>
> Absolutely. The current default is a development-time default, made because
> users were (and continue to be) confused when bundle install did not install
> gems into a location visible from `gem list`.

Correct me if I'm wrong, but couldn't that be resolved without root by
using ~/.gem as the bundle path?  (Or traversing the gem path on
exceptions to find a writable one, or offer to write the bundle path
to .gemrc, or override 'gem list' with a rubygems plugin, or etc.
etc.)

I see your logic, and I appreciate the detailed and patient response.
It still feels like insufficient reason for a deployment-breaking
change, however.  It's going in the wrong direction.  Bundler's
original appeal to me was its portability; but it's now *less*
portable and scriptable in its default state than 'gem' by itself.
(Which may emit warnings if it has to fall back to ~/.gem, but doesn't
try to force user interaction with sudo.)

I should mention that one serious problem with installing to ~/.gem can be demonstrated thusly:

$ sudo gem install rack

Password:

Successfully installed rack-1.2.1

1 gem installed

$ gem install rack

ERROR:  While executing gem ... (Gem::FilePermissionError)

    You don't have write permissions into the /usr/bin directory.

$ gem install rack --user-install

WARNING:  You don't have /Users/wycats/.gem/ruby/1.8/bin in your PATH,

 gem executables will not run.

Successfully installed rack-1.2.1

1 gem installed

$ gem uninstall rack

Select gem to uninstall:

 1. rack-1.1.0

 2. rack-1.2.1

 3. rack-1.2.1

 4. All versions

^C

$ gem --version 

1.3.6

First, notice that, by default, Rubygems 1.3.6 installs to $GEM_HOME and only $GEM_HOME (your system gem location). Second, if you explicitly install gems via --user-install, the uninstall dialog lists the same gem twice. This could (and should) be mitigated by providing the location of the gem in the case of conflicts, but the fact is that today, falling back to ~/.gem is pretty confusing.

That's especially true if we silently fall back to ~/.gem as a default.

 

> We can absolutely check for tty? and tell the user to use the --production
> flag (or, for the moment, bundle install vendor --disable-shared-gems). That
> said, once this whole thing is down to "run bundle install in development
> and bundle install --production when deploying", I think we'll be in a much
> better position.

It would certainly help, yes.  I continue to disagree with this
decision -- but I do recognize it as a thoughtful and carefully
planned one.  My concerns stand, but I _was_ able to get my own
deployment working, and time will tell whether my bigger-picture
worries are valid or an overreaction.  Thanks once again.



--

Have Fun,
   Steve Eley (sfe...@gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

--

[Stephen Eley]

On Jul 29, 2010, at 2:30 PM, Chad Woolley wrote:
>
> I don't believe this is true. Going forward, RubyGems will force you
> to pass '--user-install' if you want to install to ~/.gem, and will
> error if you try to install to a root-owned GEM_HOME without
> specifying it.

Interesting. I have similar concerns about that for similar reasons. It seems like an odd direction to take when so much of the community is putting energy into solutions (RVM, Bundler, and others) that work around Rubygems's global defaults -- I'd think that'd be a sign that people perceived the standard root location as a defect.

(In fact, one possible interpretation of this development level change in Bundler could be, "Rubygems is doing it wrong. Everyone is _used_ to having it done wrong. Ergo, we're going to do it wrong in development, and make doing it right in deployment an extra option." Argh.)

Regardless:

>
> So, stock RubyGems going forward DOES force sudo by default unless you
> pass an option.

But it doesn't. By your account, at least, it errors out. That's still superior to Bundler's new behavior of hanging while waiting for user input. Again: a lot of automated scripts are using Bundler *right now.* They're not all going to know to update their options when 1.0 comes out. If this change really is justified, then "Fail early and tell the user what to do" is much better for scripting than "Hang or time out."

> [ . . . ] And if the current behavior is what

> the Bundler devs have found to cause the minimal confusion and
> complaints in development, it's probably best to keep it that way :)

Okay, one final nitpick: the "current behavior" described in this thread has only appeared so far in the 1.0 prerelease. They may *believe* it will cause less confusion and complaint, but they can't *have found* fewer complaints to be the case yet. (I'll refrain from pointing to current evidence, as it'd be somewhat of a circular argument.) >8->

Have Fun,
Steve Eley

[Stephen Eley]

On Jul 29, 2010, at 5:28 PM, Yehuda Katz wrote:

First, notice that, by default, Rubygems 1.3.6 installs to $GEM_HOME and only $GEM_HOME (your system gem location). Second, if you explicitly install gems via --user-install, the uninstall dialog lists the same gem twice. This could (and should) be mitigated by providing the location of the gem in the case of conflicts, but the fact is that today, falling back to ~/.gem is pretty confusing.

That's especially true if we silently fall back to ~/.gem as a default.

This is a good point.  I can't really argue that Rubygems itself promotes a significant degree of confusion.  Which itself might be tied to confusing assumptions made by Ruby, which were likely inspired by the way Perl and other languages managed site- and vendor-specific dependencies, which go back to the way it's always been done in Unix, which were practical responses to organizing timeshared mainframes, and...

I dunno.  It just...  It feels to me like the Ruby ecosystem is getting a little more convoluted all the time, building new layers on top of old systems to address defects brought to light by improving practices.  It doesn't feel like _evolutionary_ complexity to me; it feels more like adding new wings onto an old house, with clashing architectural styles.

Maybe I'm just being oversensitive to my own little technical frustrations.  Maybe I'm doing it wrong myself.  This is just my perception -- that a lot of great new projects are coming out as _workarounds._  How many of the high-profile projects in the Ruby world this year have been tools abstracting other tools?  I suppose tearing down the house and building a new one seems impractical to most people, and it might be...  But the workarounds sure seem to have a high sunk cost in time and energy themselves.  I don't specifically mean Bundler.  (RVM, for instance, is a kludge.  But a _beautiful_ kludge, such that its kludginess runs deep beneath still waters. I didn't even notice until I had to explain it to someone new to Ruby.  "Wait, _why_ is this necessary?" she asked. I stammered something about environments and dependency paths until I finally said, "Don't ask. Eat your vegetables. You'll understand when you're older!")

*shrug*  I know that's fuzzy philosophizing.  Don't mind me -- I think I've finished being a smellfungus about this particular Bundler revision.  I'll continue to use it, and I know I'll make it work, and I'm pretty sure it'll even save me time overall.  

Just...don't hang on a root password prompt.  That's all I truly ask at this point.  Throw a proper exception, like 'gem' and its noisy neighbors, and I'll shut up.  I promise!

Have Fun,

Steve Eley

[Tim Uckun]

Hey Steve.

I for one appreciated your grumbling. I learned a lot out of this
discussion so for me it was an educational opportunity.

I agree with you that "there has to be a better way".

I don't know what that better way is. Maybe something like crate.
Whatever happened to that project?

[Andre Arko]

On Jul 29, 2010, at 8:41 AM, Ed Howland wrote:
> Or do I have this wrong? Should I start my project with bundle init,
> and keep updating it as I install/need gems?

Yes, the (strongly) suggested usage is to start your project with `bundle init` and update the Gemfile whenever you change your gems. Bundler is definitely focused on the development case, between multiple machines and developers. An app's gem requirements can change frequently and without notice while it is under active development, so Bundler makes coordination of gems between developers vastly easier.

The deployment case is definitely part of bundler, since it guarantees the same gems in production that were used in development, but it is not "more primary" than development.

— Andre

[Wincent Colaiuta]

On 29 jul, 19:06, Carl Lerche <m...@carllerche.com> wrote:
>
> The reason why bundler calls sudo itself as opposed to doing sudo
> bundle install is that then, all the files that bundler writes during
> install (Gemfile.lock, .bundle/config, etc...) would get owned by the
> super user, and that would be a problem (obviously). If somebody can
> explain how to work around this issue, then I would be happy to stop
> bundler from calling sudo itself.

How about this, then, when running with root privileges:

- for existing files (eg. rewriting a new Gemfile.lock etc) never
change their ownership

- for new files, rather than creating them as root-owned files, give
them the same owner as the Gemfile itself

And, just in case people complain about this being too "magic":

- provide a --user option that allows the user to override this
behavior and force ownership by a particular user

What do you think?

Cheers,
Wincent

[Wincent Colaiuta]

Bah, five minutes after writing that it occurred to me that the
proposal is over-engineered and instead we could probably learn
something from humble old "make", which is a tool with decades of
history running in a mixed unprivileged/root context.

Think about what make does in this scenario:

make # <-- only touches work tree
sudo make install # <-- only touches system, doesn't touch work tree
make clean # <-- works!

And this one:

sudo make # <-- user error! fills work tree with root-owned build
products
sudo make install
make clean # <-- fails due to earlier mistake

And finally this one:

make
sudo make install
make clean # <-- if this fails, its a bug in the Makefile

So what can Bundler learn from these patterns?

- most operations (such as "bundle check", "bundle show" and so on)
should be run without privileges

- "bundle install" should be "safe" to run as root in the sense that
it shouldn't change the ownership of the files that the "normal" ops
like "bundle check" might want to write to (likewise, it should not
create root-owned files in those places either); here I'm obviously
talking about Gemfile.lock, and stuff like .bundle/config

- it is a user error to tell Bundler to install somewhere that doesn't
require root privileges (eg. ~/.bundle, or APP_ROOT/.bundle etc) using
"sudo bundle install", as it can cause subsequent operations to fail;
but Bundler shouldn't set out to compensate for user stupidity any
more than "make" does

Some consequences:

- "bundle install" should never touch the Gemfile.lock

- the semantics of "bundle update" probably need to be changed
slightly; at the moment they effectively mean "update my Gemfile.lock
to reflect latest available versions AND install them", but it should
probably now just mean "update my Gemfile.lock to reflect the latest
available versions" (which doesn't require root privileges), and the
user can then do a "(sudo) bundle install" to actually get them in
place

- if Gemfile.lock doesn't exist at the time "bundle install" is run,
rather than creating it (which would be a bad idea when we're running
as "sudo bundle install") it should instead tell the user to run
"bundle check" first in order to create it (or even "bundle update")

Thoughts?

Cheers,
Wincent

[Ed Howland]

> --

Thanks, that clears some things up for me. I had come onto a new (for
me) Bundled project, and we were only using it for production/staging
(with development gems still changing while following Rails 3 betas).
At the time we were using git submodules (ugh!)

But I still think that "deploy.rb" style options in the Gemfile itself
would be valuable to many teams. The project itself should be as self
documenting as possible. If your project wants dependent gems to live
in APP_ROOT/vendor or APP_ROOT/.bundle, then enforcing that with 'set
:bundle_path, "vendor"' and allowing it to be overridden with a
command line option, seems the better way to go.

Note: Gemfile based options can also be encapsulated in Bundler's declarations.

group :production do
set :bundle_path, '/opt/shared/ruby/gems'
end

And, again: cap will do the right thing in a multi-project host, using
'bundle install --production'