According to the website: https://bundler.io/man/bundle-check.1.html

check searches the local machine for each of the gems requested in the Gemfile. If all gems are found, Bundler prints a success message and exits with a status of 0.

If not, the first missing gem is listed and Bundler exits status 1.

When I change a gem version in the Gemfile without running bundle install or bundle update I get the following message from bundle check:

Bundler can't satisfy your Gemfile's dependencies.
Install missing gems with `bundle install`.

And the exit status is always 0.

This is not the desired behavior. I need the exit status to be a non-zero number at least.

Environment

Bundler             1.17.1
  Platforms         ruby, x86_64-linux
Ruby                2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux]
  Full Path         /home/user/.rvm/rubies/ruby-2.5.3/bin/ruby
  Config Dir        /home/user/.rvm/rubies/ruby-2.5.3/etc
RubyGems            2.7.7
  Gem Home          /home/user/.rvm/gems/ruby-2.5.3
  Gem Path          /home/user/.rvm/gems/ruby-2.5.3:/home/user/.rvm/gems/ruby-2.5.3@global
  User Path         /home/user/.gem/ruby/2.5.0
  Bin Dir           /home/user/.rvm/gems/ruby-2.5.3/bin
Tools               
  Git               2.17.1
  RVM               1.29.4 latest
  rbenv             not installed
  chruby            not installed
  rubygems-bundler  (1.4.5)

Bundler Build Metadata

Built At          2018-10-25
Git SHA           2760d72d3
Released Version  true

Bundler settings

gem.test
  Set for the current user (/home/user/.bundle/config): "minitest"
gem.mit
  Set for the current user (/home/user/.bundle/config): true
gem.coc
  Set for the current user (/home/user/.bundle/config): false

It seems I had a wrapper function written for fish in ~/.config/fish/functions/bundle.fish so it's my fault for not handling the return value on this. Thanks!

I'm still experiencing this. To reproduce I put a gem in the Gemfile, did not install it, and then the commands above.

Environment [969/1312]

Bundler       2.1.4                                                                       
  Platforms   ruby, x86_64-linux                                                          
Ruby          2.7.1p83 (2020-03-31 revision a0c7c23c9cec0d0ffcba012279cd652d28ad5bf3) [x86_64-linux]
  Full Path   /home/danielpclark/.rbenv/versions/2.7.1/bin/ruby
  Config Dir  /home/danielpclark/.rbenv/versions/2.7.1/etc
RubyGems      3.1.4            
  Gem Home    /home/danielpclark/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0                
  Gem Path    /home/danielpclark/.gem/ruby/2.7.0:/home/danielpclark/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0
  User Home   /home/danielpclark             
  User Path   /home/danielpclark/.gem/ruby/2.7.0                                          
  Bin Dir     /home/danielpclark/.rbenv/versions/2.7.1/bin
Tools                                                                                     
  Git         2.25.1                                                                      
  RVM         not installed                                                               
  rbenv       rbenv 1.1.2-11-gc46a970     
  chruby      not installed                                                                                                                                                         

Bundler Build Metadata

Built At          2020-06-03                                                                                                                                                        
Git SHA           32a4159325                                                              
Released Version  false

Ruby 2.3.7 & 2.4.4 fail on CI servers for all OSes because of the is_frozen check here. Works with Ruby 2.5.1 everywhere though and works on both my machine and Docker with all Ruby versions. <strike>May be CI binaries related</strike> but that doesn't explain why is_frozen works elsewhere on the CI same systems. Either get this to work on the CI servers or wait till EOL for Ruby 2.3 and 2.4.

if self.is_frozen() {
    return Err(AnyException::new("FrozenError", Some("can't modify frozen String")));
}

https://github.com/danielpclark/rutie/blob/master/src/class/string.rs

I've tried it with send("frozen?", protect_send("frozen?", rb_obj_frozen_p, and re-implemented is_frozen completely in Rust with bit flags and they all produced the same results described above.

This should fix #128 and make rutie warning-free on rust v1.46.

Our CI just bumped the Rust toolchain to 1.46 and we started seeing FFI errors. I would expect the safe FFI annotations to be declared by Rutie, so all projects that use this library don't need to change their code, but I don't know if that's possible.

These are the errors:

15 | class!(BundleRemaps);
   | ^^^^^^^^^^^^^^^^^^^^^
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: `extern` fn uses type `BundleRemaps`, which is not FFI-safe
  --> mesh-ruby/src/lib.rs:19:5
   |
19 |     BundleRemaps,
   |     ^^^^^^^^^^^^ not FFI-safe
   |
   = help: consider adding a `#[repr(C)]` or `#[repr(transparent)]` attribute to this struct
   = note: this struct has unspecified layout
note: the type is defined here

@NeoLegends

But why does this have to do anything with merging and releasing this PR?

The tests would not pass for Stable or Nightly and that is what this project tests against. I believe I'll need to update it so that every local trait implements this instead of the more convenient way that has. This is highly depended upon.

I must have missed some changes to the Rust language. This evening I couldn't get past the following:

error[E0210]: type parameter `Obj` must be used as the type parameter for some local type (e.g., `MyStruct<Obj>`)
    --> src/class/traits/object.rs:1401:1
     |
1401 | impl<Obj: Object> From<Value> for Option<Obj> {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type parameter `Obj` must be used as the type parameter for some local type
     |
     = note: only traits defined in the current crate can be implemented for a type parameter

error: aborting due to previous error

I'll have to look into this more another day.

@NeoLegends @calavera I'll try and get to this and make a release this evening.

This allows people to use Option<SOME_VERIFIED_OBJECT> in method signatures instead of taking AnyObject and converting.

@pwoolcoc Thanks! This is nice!