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
course ENV is inherited from the parent process. Since after I realized this,
it's fairly easy to workaround that:
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
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.
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 ofcourse 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
Note: Only a member of this blog may post a comment.