What have you found for these years?

2012-03-21

bundler is infecting ENV

I just don't get why I would get bundler error in a sub-process of Ruby invoked
from a shell. It worked perfectly fine when I run it from my shell directly.
It doesn't make sense to have bundler affecting sub-process unless MRI is
doing the same thing as JRuby, i.e. reusing an existing Ruby process from shell
invocation whenever the shell command contains the string "ruby", which is
a very dirty hack in my opinion. But that's another story anyway.

So I just looked into bundler's source, (always remember to use the source, Tux)
realizing that it is infecting ENV with BUNDLE_GEMFILE and RUBYOPT, and of
course ENV is inherited from the parent process. Since after I realized this,
it's fairly easy to workaround that:

ENV.delete('BUNDLE_GEMFILE')
ENV.delete('RUBYOPT')

That's it. Put that before spawning a new sub-process.
This is very wrong in my opinion, causing the sub-processes
cannot use different Gemfile once a Gemfile is loaded.
Hey, we're in different processes, what's the point of
using the the same Gemfile? Touching RUBYOPT is also horrible.

Anyway, since it's not hard to workaround it, I am not too
strongly against it if someone really wants that for some
unknown reasons...

Just need to remember there's a TRAP!

p.s. Also, bundler's code is very hard to read at all. I am
not very interested in improving it... after several attempts.

0 retries:

Post a Comment

All texts are licensed under CC Attribution 3.0