A story of PROMPT_COMMAND and RVM
It’s a bit over a year as I work as RVM maintainer with over one and half year (19 months) of contributing to the project.
As I work on the project it was always improved, we spent a lot of time responding to user requests. At first I was helping Wayne E. Seguin the original author and later I took over as maintainer. We have been working hard in our free time to improve the first ruby environment switcher. We also had a lot of ideas how to make things better, but because it was our free time we were not always able to make all the ideas happen even implementing them would be as simple as just few lines change.
Today I want to share history of one of that ideas, automatic environment switching using a shell hook PROMPT_COMMAND => http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/x264.html, it is very easy idea allowing to execute piece of code every time user prompt is to be displayed. It was supposed to solve some limitations of overwriting builtin change directory command – cd, especially not rereading project file when it’s updated.
Before we were able to implement it a new project come to life – rbenv, it was also intended to do the environment switching but a lot simpler. Among of a lot of promotional keywords rbenv was accusing rvm of overwriting cd, which is considered harmful by rbenv author. To not feed the propaganda of a new tool rvm team has dropped all ideas related to accusations from rbenv. Among other interesting ideas rvm dropped also the idea of using PROMPT_COMMAND.
As time passes a lot of new tools was created to do the same thing – switching ruby environments. One of the tools is chruby, one of the most minimalistic implementations. I was helping from time to time the author with shell code, with understanding the problem of switching environment or just discussing various aspects of the tools we work on.
Of course there was also a need for automated switching of environment in chruby, the author started with cd function implementation as this is one of the easiest ways to archive this functionality. But then I have remembered of PROMPT_COMMAND and proposed use of it, which after quick test appeared to be better solution.
Seeing the idea working I have decided to implement it also for rvm, as initially expected this is a lot simpler code and solves some of the issues. We could have this code available for rvm users one year ago, possibly we could have a lot more of good solutions if the problems were discussed instead of throwing accusations as it was done by rbenv author.
So I wanted to sum the situation here, I wanted to disapprove the method of promoting opensource in cost of other opensource software without bringing discussion, without opening not a single ticket for the project. This are practices that you use fighting “corporate” world, as opensource authors we can choose to work together put aside all the politics, and do our work together for common benefit.
On the end I would thank postmodern the author of chruby for bringing up the discussion and working towards standardizing our software.
@Matt
That’s the kind of FUD that Sam started, we take it all into account, your
PROMPT_COMMANDwill be appended not overwritten. The shell will not be slower more then with cd as the found project file is recorded and will not be loaded unless necessary.Would this overwrite the custom prompt_command I already have for my own shell? The contents of which needs to be run first, at the very least?
Not to mention, for shell purists, all this does is slow down every prompt command that you have to wait for after hitting enter.
@Andrew Grimm
RVM was fully functional product long before rbenv was created, so there was no way to cripple RVM – using PROMPT_COMMAND does not fix any issues, it just adds a new feature.
@Andrew Dupont
I do not think that Sam actually has issues with the sole fact that “cd” is overwritten, there is no real issue in this as long the underlying code works good and this option itself is used by few tools, Sam’s reasoning “Override shell commands like cd. That’s dangerous and error-prone.” does not follow any documented errors, does not link to a issue reports, but for next points he includes links.
I understand that the function implementation that overwrites “cd” might have errors and I do not want to argue about that, but overriding “cd” itself is not dangerous or error prone more then writing any other code (like rbenv shims), not giving any documentation links for that proofs it was just a FUD.
As I explained in my response to Rupert there was no discussion with Sam, even he knew how it feels being treated like this he did the same to our team. We were anxious in trying ideas that did not have to bring value but their failure would be clearly turned by Sam as his victory. Only time proved that this solution was good (although I’m still waiting for problem reports as it just got implemented and only testing by thousands of users show pitfalls).
“Among of a lot of promotional keywords rbenv was accusing rvm of overwriting cd, which is considered harmful by rbenv author. To not feed the propaganda of a new tool rvm team has dropped all ideas related to accusations from rbenv.”
How childish.
Choosing to cripple your own product for such reasons is not in the best interest of the user, and is not trustworthy behavior.
And trust is important with a project like rvm, for example trusting that it won’t delete ~/ruby .
Michael, if I understand correctly, this is what you’re saying: rbenv wasn’t interested in debating the merits of its approach versus RVM’s; it was only interested in spreading FUD against RVM because it would help gain adoption of his tool.
I can see where you’re coming from. Part of me bristles at tools that were created to be a “better version” of something else, rather than promote themselves on their own merits.
But that doesn’t mean that the criticism was unwarranted. If Sam feels that overriding
cdis dangerous and error-prone, it’s not necessarily his obligation to change Wayne’s mind or yours.What’s surprising to me (and to Rupert and Geoff as well, it seems) is the idea that you’d purposefully discard suggestions like
PROMPT_COMMANDbecause you didn’t want to hand rbenv a propaganda victory. You say…“We could have this code available for rvm users one year ago, possibly we could have a lot more of good solutions if the problems were discussed instead of throwing accusations as it was done by rbenv author.”
…but there was nothing preventing you from implementing
PROMPT_COMMANDa year ago. It’s your code. I understand the reasoning behind that decision, but it doesn’t mean that it’s rbenv’s fault that you made the decision you made.You’re right that this did happen to Sam before with Prototype. Sam (and we others on the Prototype team) did endure a lot of criticism, lots of it unconstructive, about how it was wrong to extend built-ins. But, having heard that criticism, we stuck with our philosophy. Not because we didn’t want to admit others were right, but because we thought our philosophy was sound.
@Mislav
Ah sorry I meant proof it will work (at all) and the code would be actually simpler compared to cd hook, it’s even simpler then I thought it would be.
@Michal Papis I think actually releasing it in chruby and having people use it first for a while would actually “prove” it was a good idea. Proof is not just throwing ideas around on issue trackers.
@Geoffrey Grosenbach
At the time I did not know it will be better or worse, only helping chruby proved it was good idea
@Rupert Madden-Abbott
It’s fine, I did not wanted to go in to many detail in the post, it’s already TL;DR.
So when rbenv was started it was promoted by blaming RVM for doing “evil” things one of them being overwriting “cd”, a lot of users just raised voice it’s very bad that RVM does it without even thinking if it’s bad or how it could be bad.
This was very uncomfortable position where any move will be perceived bad because the aim of rbenv creator was not discussion but promotion of his own software and he could turn any action as a proof that he is right and his tool should be used. This is the part I did not liked about promotion of rbenv, there was no discussion, it was never the aim.
Using blame instead of discussion kills the involvement in opensource which is in biggest part created by enthusiasts, very often after work. The way it was done as I understand already happened once to Sam Stephenson and you can see that it killed his work on opensource to only job related activities, now he did the same to Wayne E. Seguin, I do not think anyone can justify this.
The wording of this post makes it sound as if you knew of an improvement to rvm that would benefit the users of your software, but chose to not implement it because of rbenv’s marketing.
Is this what you’re saying?
Could you expand on this point:
“To not feed the propaganda of a new tool rvm team has dropped all ideas related to accusations from rbenv. Among other interesting ideas rvm dropped also the idea of using PROMPT_COMMAND.”
I don’t understand why the rbenv criticisms of rvm affected what you were doing with rvm and, specifically, the dropping of the PROMPT_COMMAND idea.
Sorry for being dense!
@uki If you would follow the code you would see it is almost the same for ZSH, what rbenv does has also it’s own drawbacks, I wrote in more detail about it here: http://niczsoft.com/2011/11/what-you-should-know-about-rbenv-and-rvm/
Still, using PROMPT_COMMAND works only in bash, rbenv works in every shell, without any artificial “need bashizm’s support”.