Bundler::Gemnotfound: Could Not Find Mimemagic-0.3.5 in Any of the Sources on Rails Project with Docker

Bundler::GemNotFound: Could not find mimemagic-0.3.5 in any of the sources on Rails project with Docker

bundle update --conservative mimemagic 

also try with newer version rather than locking it.
it worked for us with 0.3.9, but now there is 0.3.10(have not tried it),

Your bundle is locked to mimemagic (0.3.5), but that version could not be found in any of the sources listed in your Gemfile

Few days ago, the mimemagic versions were yanked. More info can be found at:

• https://github.com/rails/rails/issues/41750
• https://rubygems.org/gems/mimemagic/versions

You can modify your Gemfile as below:

gem 'mimemagic', github: 'mimemagicrb/mimemagic', ref: '01f92d86d15d85cfd0f20dabd025dcbd36a8a60f'

Bundler could not find rake in any of the resources

I'm not really sure what happened and why but I tried doing this on my rails container and I was no longer receiving the said error.

1. docker-compose run --rm <container> bash
2. cd to project directory
3. bundle install

Rails bundle Can't find GEM in any of the sources in Docker Container only

You're mounting a named volume over the container's /usr/local/bundle directory. The named volume will get populated from the image, but only the very first time you run the container. After that the old contents of the named volume will take precedence over the content of the image: using a volume this way will cause Docker to completely ignore any changes you make in the Gemfile.

You should be able to delete that volumes: line from the docker-compose.yml file. I'm not clear what benefit you would get from keeping the installed gems in a named volume.

The path `/app/include/engine` does not exist. (Bundler::PathError)

it because of this line

  volumes: 
    - ".:/app"

This mounts your local dir inside the container when starting overwriting existing data already in the image. This means everything in /app is replaced with data from your local machine including your engine /app/include/engine.

To fix this you need to have this engine cloned in your local folder so it is available when starting the container. An other option is to clone the engine outside /app for example in /tmp or whatever you like.

Too many versions of Ruby in my app - which one are really necessary?

You usually should not use a version manager with Docker (asdf, rbenv, rvm, ...). At a mechanical level, most paths to running a Docker container don't read the .bashrc or .profile files you set up, and you need a pretty roundabout path to "activate" the version manager. Style-wise, the Docker image contains only a single application and its runtime, so you'll only ever need a single Ruby version within the context of its container, and the image's FROM line is enough.

You should keep the ruby constraint in your Gemfile, which helps ensure you have a compatible version of Ruby in other environments (for example, using asdf in your non-Docker desktop setup). And you need a Ruby version in your image's FROM line so Docker knows which base image to use.

In your example, without installing or invoking asdf, the base image already has Ruby 3.1 available, so you don't need to do any additional work to (re)install it.

---

Related Topics