bundler 1.0 issues with system calls

[anywho]

Please check out my repo at: http://github.com/danielb2/bundler-1.0-oddness

which explains the issue also.

basically when using bundler 1.0, if you've loaded Bundler.setup any
calls to bundle install in a system call will run bundle install for
that Gemfile, even if you're in a different current working directory.

Bundler.setup
system "cd /some/totally/different/path && bundle install"

Will still run the bundle install for the Gemfile in the dir relative
to the Bundler.setup.

See my github repo for a reproducable case.

[Yehuda Katz]

This is intentional.

If you don't want to inherit bundler when shelling out, you can do:

Bundler.with_clean_env do

  system "shell out"

end

Yehuda Katz
Architect | Engine Yard
(ph) 718.877.1325

--
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.

[anywho]

I bet a lot of people will stub their toes on this ( and I wasted a
fair amount of time tracking this down )

Wouldn't

Bundler.with_inherited_env do
system ""
end

been better? What was the reasoning?

I also noticed this isn't documented on gembundler.com.

> > ruby-bundler...@googlegroups.com<ruby-bundler%2Bunsubscribe@google groups.com>
> > .

[Kunal Shah]

fwiw this is a big gotcha for a number of people on my team as well

> To unsubscribe from this group, send email to ruby-bundler...@googlegroups.com.

[Yehuda Katz]

It actually is documented in the bundle exec man page: http://gembundler.com/man/bundle-exec.1.html#ENVIRONMENT-MODIFICATIONS

The reason for this is that there are gems (like rspec) that shell out to themselves at runtime. This is *so common* that this needs to be the default. That said, I have recently been pondering: bundle --dont-inherit exec command

Yehuda Katz
Architect | Engine Yard
(ph) 718.877.1325

To unsubscribe from this group, send email to ruby-bundler...@googlegroups.com.

[anywho]

Previous behavior was changed, and it (unexpectedly) changes the
functionality of a core ruby function.

"It’s tempting, nonetheless, to customize Ruby to your liking by
changing core methods globally. After all, you can. But this is the
least safe and least advisable approach to customizing core-object
behaviors."
"don’t change the documented behavior of core Ruby methods. "

-- David Black, The Well-grounded Rubyist.

On Aug 31, 10:04 pm, Yehuda Katz <wyc...@gmail.com> wrote:
> It actually is documented in the bundle exec man page:http://gembundler.com/man/bundle-exec.1.html#ENVIRONMENT-MODIFICATIONS
>
> The reason for this is that there are gems (like rspec) that shell out to
> themselves at runtime. This is *so common* that this needs to be the
> default. That said, I have recently been pondering: bundle --dont-inherit
> exec command

> <http://gembundler.com/man/bundle-exec.1.html#ENVIRONMENT-MODIFICATIONS>

[Yehuda Katz]

Actually, we don't touch #system at all.

We simply update $RUBYOPT to automatically activate the bundle. And I can tell you frankly that the number of bug reports we receive WITHOUT this behavior is far more than the alternative. Both cases are confusing for users. We have to pick the more common one to default.

Yehuda Katz
Architect | Engine Yard
(ph) 718.877.1325

To unsubscribe from this group, send email to ruby-bundler...@googlegroups.com.

[anywho]

Thanks for the detailed explanation.

[Ethan]

I ran into this issue this week, and found the bug report at
http://github.com/carlhuda/bundler/issues/issue/478/ (and commented
there).

I appreciate that supporting changes that affect launched ruby
processes is no easy task, and that either way you go you will have to
deal with people complaining. Choosing the solution that gets fewer
complaints is easier, but wrong.

A very simple reason why it's wrong is that, without knowledge of
bundler, currently this issue cannot be worked around for libraries
that launch other ruby processes. That is, a library has to remove
bundler's meddling from RUBYOPT, and know to look for the "-r bundler/
setup" to remove it (or, detect if a method Bundler.with_clean_env
exists and use that). This is extremely undesirable, and expecting any/
every library which wishes to launch a clean ruby process to be aware
that bundler may have meddled, is not reasonable.

Even if it is considered acceptable that every other ruby-launching
library should work with or around Bundler, that assumes that bundler
is unique. If this is deemed acceptable behavior, then every library
will have to do the same thing for any other thing that may decide to
add itself into RUBYOPT. It's out of hand already with bundler doing
this; it's a complete nightmare when some other library (say a new
competitor to bundler, or whatever) starts doing it (repeat N times).

On the other hand, the main problem with not setting up bundler in
spawned ruby instances, by my understanding (I may be wrong; I'm sure
I will be corrected if so), is the $LOAD_PATH. A spawned ruby won't
know to look in bundler's paths. However, it is perfectly possible for
libraries to launch other ruby processes with the changes that bundler
makes without any knowledge of bundler itself, by invoking ruby with -
I flags corresponding to its own current $LOAD_PATH. Plenty of things
change the $LOAD_PATH (bundler, rubygems, other gems, etc) and things
that launch other ruby processes must be aware that they're going to
need to tell the spawned ruby where to look for things.

Rubygems has managed to get by without inserting itself into RUBYOPT.
Replicating the load path for spawned ruby processes so that they can
find gems must be a more common problem for rubygems than for bundler
(I have dealt with this issue myself with rubygems). If rubygems
(being much more prevalent) doesn't need to do this, I don't think
there is good reason (or sufficient reason, anyway) for bundler to do
so.

Please reconsider removing this awful behavior from bundler.

-Ethan

[Yehuda Katz]

I replied to the bug report at http://github.com/carlhuda/bundler/issues/issue/478/#issue/478/comment/387842. I understand why if you hit this issue from your perspective it would seem *OBVIOUS* that the behavior was wrong. Unfortunately, the people who hit the issue from the other perspective also feel it's *OBVIOUS* that the other behavior was wrong.

If you can think of a solution that's better than allowing `bundle --dont-inherit exec rspec spec` (which is planned for 1.1), I'd love to hear it. I mean that sincerely, since this problem is difficult no matter how you slice it.

Yehuda Katz
Architect | Engine Yard
(ph) 718.877.1325

To unsubscribe from this group, send email to ruby-bundler...@googlegroups.com.