error when there is a invalid Gemfile in the current directory
mat813 opened this issue · 12 comments
Trying to jist a file and I get:
$ jist out
/Users/mat/.rvm/gems/ruby-1.8.7-p370@global/gems/bundler-1.1.5/lib/bundler/dsl.rb:12:in `evaluate': There was an error in your Gemfile, and Bundler cannot continue. (Bundler::GemfileError)
from /Users/mat/.rvm/gems/ruby-1.8.7-p370@global/gems/bundler-1.1.5/lib/bundler/definition.rb:18:in `build'
from /Users/mat/.rvm/gems/ruby-1.8.7-p370@global/gems/bundler-1.1.5/lib/bundler.rb:135:in `definition'
from /Users/mat/.rvm/gems/ruby-1.8.7-p370@global/gems/bundler-1.1.5/lib/bundler.rb:123:in `load'
from /Users/mat/.rvm/gems/ruby-1.8.7-p370@global/gems/rubygems-bundler-1.0.6/lib/rubygems-bundler/noexec.rb:41:in `candidate?'
from /Users/mat/.rvm/gems/ruby-1.8.7-p370@global/gems/rubygems-bundler-1.0.6/lib/rubygems-bundler/noexec.rb:60:in `setup'
from /Users/mat/.rvm/gems/ruby-1.8.7-p370@global/gems/rubygems-bundler-1.0.6/lib/rubygems-bundler/noexec.rb:75
from /Users/mat/.rvm/rubies/ruby-1.8.7-p370/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:60:in `gem_original_require'
from /Users/mat/.rvm/rubies/ruby-1.8.7-p370/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:60:in `require'
from /Users/mat/.rvm/gems/ruby-1.8.7-p370/bin/ruby_noexec_wrapper:9
Also, jist is not in that Gemfile, if it would ever help :-)
I don't know if I would consider this an error, since we do read the Gemfile and we do expect it to be valid so it's perfectly reasonable this happens, is there something else you expected to happen other than the command to run successfully (because we do wrap around bundler it should fail if you ask me) but I'm open to hearing out suggestions and I'm sure @mpapis is too.
Well, I don't expect the Gemfile to be read if I don't do bundle exec, or launch a command like rails that will load it up.
Doesn't that sort of go against what this gem is meant to do?
Well, no, let me rephrase, I don't expect the Gemfile to get in the way when I try to launch a command, in that case, jist is not even in the Gemfile.
I mean, if the Gemfile has a problem, at most, it should emit a warning and continue as if it was not there.
IMO that still defeats the purpose of this Gem. If you use Bundler to install something and then we intern build a wrapper around Bundler you cannot expect us or Bundler to avoid your Gemfile, that not only defeats the purpose of our Gem but Bundler itself.
You can however tell rubygems-bundler not to build wrappers around certain gems with exclude (https://github.com/mpapis/rubygems-bundler#noexecyaml) when you bundle install and if you install into the 'system Gempath' it will avoid Bundler at that point (as long as you do not bundle exec jist)
That said, it's also really not us causing the error, it's Bundler.
this is an extra case, rubygems-bundler should not error in this case, if the Gemfile is not usable (Bundler::GemfileError) then the best solution would be to just fallback to the default behavior - not using the Gemfile, we can add an debug message about that, but I do not think a warning would be in place here.
I'm still 👎 I would expect this behavior 💨
if the Gemfile is in 1.9 format (hashes) then under ruby 1.8 it will fail
@mpapis brings up good points, even though I think you should fix your Gemfile and such, it's not too bad for us to allow it go through and just tell you that there is a problem with your Gemfile. Sort of an annoyance + don't fail type of situation that way you remember to fix it later. We are probably gonna group this up with #37
Well, the thing is, this gem is installed by default with RVM, I did not even know it existed or what it did before I got this error yesterday.
I really believe that it should be as transparent as it could, and in that case, and certainly some other, it means not crashing and dropping the Gemfile completely :-)
will be released as 1.2.0.rc1
released as 1.2.0.rc1