You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Dev-tools supports rbenv while Conductor uses rvm. Both tools have the same purpose and I think we should use only one of them in all Aeolus subprojects.
The text was updated successfully, but these errors were encountered:
I can't see that happening, as people who use each tool feel strongly about their choice. Further, I don't think there is any reason they have to be mutually exclusive. Each tool is only going to use its own config file, but I agree that we should not have rvm in one place and rbenv in another. Really, if anything, I think this issue should become a request for rvm support (which I would fully back), especially since it is already used in both conductor and tim (and alberich, I believe).
To clarify a bit, when dev-tools sets up the development environment for Conductor (with system ruby or rbenv), it relies on bundler and Conductor's Gemfile to install gem dependencies. So, the user should still be getting a proper development environment per se.
If someone wants to add rvm support to dev-tools, I would support that too. Not being a big rvm user, I assume it would feasible to do that in the existing bootstrap.sh (sidebar: whether this should be broken up into multiple scripts is another issue) by looking for a environment variable like RVM_VERSION much as the current script has support for RBENV_VERSION. The current script has the philosophy of not mucking with the user's default shell functions / environment variables and I'm not sure that would be the case anymore if we added rvm support, but I'll defer to the rvm experts.
Dev-tools supports rbenv while Conductor uses rvm. Both tools have the same purpose and I think we should use only one of them in all Aeolus subprojects.
The text was updated successfully, but these errors were encountered: