Ignore Read-Only Filesystems for Compile Cache

[metaskills]

I am using Bootsnap with AWS Lambda and previously submitted a path in #355 for the load path cache. While testing the compile cache today I noticed the following error and stack trace. The pull request mirrors the work done in #355 but instead applies this to the YAML.load_file which has Bootsnap::CompileCache::YAML::Patch prepended to it.

I am not super happy with the test and would appreciate any feedback. This test feels a little white box because I know it will call Bootsnap::CompileCache::Native.fetch under the hood. Again, feedback welcome.

Errno::EROFS: Read-only file system - bs_fetch:atomic_write_cache_file:mkstemp (Most recent call first)

File /var/task/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.7.3/lib/bootsnap/compile_cache/yaml.rb line 117 in fetch
File /var/task/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.7.3/lib/bootsnap/compile_cache/yaml.rb line 117 in load_file
File /var/task/vendor/bundle/ruby/2.7.0/gems/i18n-1.8.9/lib/i18n/backend/base.rb line 243 in load_yml
File /var/task/vendor/bundle/ruby/2.7.0/gems/i18n-1.8.9/lib/i18n/backend/base.rb line 226 in load_file
File /var/task/vendor/bundle/ruby/2.7.0/gems/i18n-1.8.9/lib/i18n/backend/base.rb line 18 in block in load_translations
File /var/task/vendor/bundle/ruby/2.7.0/gems/i18n-1.8.9/lib/i18n/backend/base.rb line 18 in each
File /var/task/vendor/bundle/ruby/2.7.0/gems/i18n-1.8.9/lib/i18n/backend/base.rb line 18 in load_translations
File /var/task/vendor/bundle/ruby/2.7.0/gems/i18n-1.8.9/lib/i18n/backend/simple.rb line 80 in init_translations
File /var/task/vendor/bundle/ruby/2.7.0/gems/i18n-1.8.9/lib/i18n/backend/simple.rb line 50 in available_locales
File /var/task/vendor/bundle/ruby/2.7.0/gems/i18n-1.8.9/lib/i18n/config.rb line 45 in available_locales
File /var/task/vendor/bundle/ruby/2.7.0/gems/i18n-1.8.9/lib/i18n/config.rb line 51 in available_locales_set
File /var/task/vendor/bundle/ruby/2.7.0/gems/i18n-1.8.9/lib/i18n.rb line 337 in locale_available?
File /var/task/vendor/bundle/ruby/2.7.0/gems/i18n-1.8.9/lib/i18n.rb line 343 in enforce_available_locales!
File /var/task/vendor/bundle/ruby/2.7.0/gems/i18n-1.8.9/lib/i18n.rb line 199 in translate
File /var/task/vendor/bundle/ruby/2.7.0/gems/activemodel-5.0.7.2/lib/active_model/naming.rb line 189 in human
File /var/task/vendor/bundle/ruby/2.7.0/gems/activemodel-5.0.7.2/lib/active_model/errors.rb line 498 in generate_message
File /var/task/vendor/bundle/ruby/2.7.0/gems/activemodel-5.0.7.2/lib/active_model/errors.rb line 528 in normalize_message
File /var/task/vendor/bundle/ruby/2.7.0/gems/activemodel-5.0.7.2/lib/active_model/errors.rb line 331 in add

[casperisfine]

I'm ok on principle, but I'd rather handle this in the extension. I'll have a look tomorrow.

[casperisfine]

Also, if I remember your use case correctly, you are building a docker image and then it's mounted on read only FS. It would probably be best for you to load I18n during the image build to pregenerate these caches, or to feed these YAML files to bootsnap precompile

[metaskills]

Thanks. I can confirm both of these work.

$ bundle exec bootsnap precompile --gemfile .
$ bundle exec bootsnap precompile --gemfile app/ lib/ config/

I think for us we will stick with the present working directory since prior to precompiling we clean the test directory and other unneeded files. So a few questions:

1. Any other issue you can think of or why we should not use .?
2. Do you see a need for this pull request? As is, changed, docs, etc?

[casperisfine]

1. Any other issue you can think of or why we should not use .?

No, I use it myself on our projects. Depending on your project layout it could cause some extra pre-compilation, but usually it's not a big deal.

Do you see a need for this pull request? As is, changed, docs, etc?

I don't think docs need to be changed, as we're really into big edge case territory here.

[metaskills]

You thinking close this PR then?