> Which is exactly why it's a terrible idea. There is no "super" mechanism in Bash. Imagine if the Perl, Python and Node equivalents of rvm overrode cd -- they'd all have to be aware of each other's existence in order to play together nicely.
That would be a problem until rvm fixed it. Then its users would have to update it. It's not ideal, I know, but rvm is very much an active solution. Because it's used to install rubies, which get updated, its users update it.
That's one great thing about rbenv: it's easier to write, and thus easier to write clones. I'm looking forward to seeing a node.js developer adopting your shim approach. By the way, I'm glad they're plain sh scripts, so I can still use Xavier Shay's technique for making no-dependency ruby scripts fast. The rubygems wrapper scripts run a lot of code and don't provide a convenient option to skip it if it's not needed. By the way it would be cool if, with a plugin of sorts, reshim could remove require 'rubygems'. It could get people running more than one ruby CLI tool at a time (with pipes and/or backquotes) more often by shaving off the approximately half-second rubygems load time.
> Overriding cd for dependency injection purposes is like killing a fly with a machine gun. It's completely inappropriate for the task at hand, and it's precisely the kind of problem that $PATH is designed to solve.
I like your shim approach but while it may be obvious to you, I found it quite clever. I think virtualenvwrapper could use it. I don't think it was like killing a fly until you introduced this idea, which most of us hadn't heard of or considered.
> Furthermore, rvm breaks the expected behavior of the cd command by prompting you with security theatrics the first time you enter a project with an .rvmrc file: https://gist.github.com/34c251a56e83c61c667e This kind of thing wreaks havoc with third-party programs that attempt to interface with rvm. I've had to deal with far too many bug reports in Pow as a result of this messy behavior.
You were using it in a different way than most, up until you wrote pow, and found a weak point. The trust database should have a way to inspect it, and it should have been documented. It's frustrating, I know.
> This is not some theoretical concern. It's just bad design.
I don't think the rvm, virtualenv, or virtualenvwrapper developers particularly liked designing (or attempting to design) this part of their system. If they could have skipped out on this feature and still have the benefit, I think they would have. I'm glad you found a path that you enjoyed taking to solve this problem.
By the way I'm a happy pow user and I'm glad you wrote rbenv since it makes pow easier for you to support and maintain. I hope it helps me to use my rvm-installed rubies with pow.
That would be a problem until rvm fixed it. Then its users would have to update it. It's not ideal, I know, but rvm is very much an active solution. Because it's used to install rubies, which get updated, its users update it.
That's one great thing about rbenv: it's easier to write, and thus easier to write clones. I'm looking forward to seeing a node.js developer adopting your shim approach. By the way, I'm glad they're plain sh scripts, so I can still use Xavier Shay's technique for making no-dependency ruby scripts fast. The rubygems wrapper scripts run a lot of code and don't provide a convenient option to skip it if it's not needed. By the way it would be cool if, with a plugin of sorts, reshim could remove require 'rubygems'. It could get people running more than one ruby CLI tool at a time (with pipes and/or backquotes) more often by shaving off the approximately half-second rubygems load time.
https://github.com/xaviershay/xtdo
> Overriding cd for dependency injection purposes is like killing a fly with a machine gun. It's completely inappropriate for the task at hand, and it's precisely the kind of problem that $PATH is designed to solve.
I like your shim approach but while it may be obvious to you, I found it quite clever. I think virtualenvwrapper could use it. I don't think it was like killing a fly until you introduced this idea, which most of us hadn't heard of or considered.
> Furthermore, rvm breaks the expected behavior of the cd command by prompting you with security theatrics the first time you enter a project with an .rvmrc file: https://gist.github.com/34c251a56e83c61c667e This kind of thing wreaks havoc with third-party programs that attempt to interface with rvm. I've had to deal with far too many bug reports in Pow as a result of this messy behavior.
You were using it in a different way than most, up until you wrote pow, and found a weak point. The trust database should have a way to inspect it, and it should have been documented. It's frustrating, I know.
> This is not some theoretical concern. It's just bad design.
I don't think the rvm, virtualenv, or virtualenvwrapper developers particularly liked designing (or attempting to design) this part of their system. If they could have skipped out on this feature and still have the benefit, I think they would have. I'm glad you found a path that you enjoyed taking to solve this problem.
By the way I'm a happy pow user and I'm glad you wrote rbenv since it makes pow easier for you to support and maintain. I hope it helps me to use my rvm-installed rubies with pow.