-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
With RVM use _current_ ruby and gemset, not _default_ #201
Conversation
I was getting errors, when trying to use rubocop in pre-commit, because it couldn't be found. But I had installed it in the current gemset. The problem was, that pre-commit was not using the _current_ gemset, but the _default_. This commit fixes that.
the git config pre-commit.ruby "rvm `rvm current` do ruby" or git config pre-commit.ruby "rvm current do ruby" closing as this would change the planned / expected behavior and you have options to change this with |
Please explain, why this is the intended behavior. The whole point of rvm and gemsets is, that when you are in a certain directory you will use the ruby version and gemset that is configured. By using the default ruby and gemset you are breaking this: If I add "pre-commit" to my Gemfile and run bundler, I will not be able to use it:
I would need to go to a directory without a rvm configuration and 'gem install pre-commit' there (and rubocop), so it appears in my default gemset. That doesn't make a lot of sense. |
we( to install rvm default do gem install pre-commit |
This assumption is in direct conflict with the RVM approach, which is that I can take complete control of the ruby environment that I am currently using. Having to use the same version of pre-commit, execjs and rubocop (and dependencies) in all projects is not what RVM is made for. Why don't you invert that assumption and say, that if someone wants to use a global (default) version, he can do so by configuring it:
But make pre-commit use the current gemset by default? |
from RVM side - the problem with |
Unfortunately this is the number one issue with this gem. Everyone has different environment setups and everyone wants it to work out of the box their way, in their environment. We obviously want to make this work properly for as many people as possible. Unfortunately, I have not collected any stats on which environments everyone uses over the years. As @mpapis pointed out, we try to provide configuration hooks to make everyone happy. There are options to configure your preferred Ruby using git configuration. There are also multiple hook templates Again, I'm on board with using settings that make the most people happy, and if that means using the current gemset, I'm all for it (but that also assumes most people are using RVM, and are using gemsets). Of course, when / if a breaking change like happens, it would require a major version bump. |
well you do not need to stick to semantic versioning before you reach |
Adding another template sounds reasonable. The very least that should happen is to add documentation about the fact that the standard installation does not use the current gemset. I could write the |
we can achieve the same result as with |
I was getting errors, when trying to use rubocop in pre-commit, because it couldn't be found. But I had installed it in the current gemset. The problem was, that pre-commit was not using the current gemset, but the default. This commit fixes that.