Open jarrodldavis opened 3 years ago
These were not in the containers originally in the containers, but developers requested them be added so they can take advantage of the related config files. So, removing them is not ideal.
That said, we can, however, "eat" these messages and prevent them from appearing or allow disabling them as you mention.
This ENV based to disable rbenv / rvm based on an environment variable would also apply to the codespaces-linux image.
This is also causing issues with the Ruby VS Code extension for me, which seems to detect rbenv/rvm being present and tries to load Ruby through them (instead of using the container's system Ruby): Required ruby-3.0.2 is not installed.
I'm moving towards using leaner custom devcontainer Dockerfile
s based directly off the upstream ecosystem images (e.g. ruby:3
, because the "kitchen sink" approach of these official VS Code images doesn't really work for me personally. Having the ability to more aggressively disable a lot of this stuff might tempt me back 😃
This is also causing issues with the Ruby VS Code extension for me, which seems to detect rbenv/rvm being present and tries to load Ruby through them (instead of using the container's system Ruby):
Required ruby-3.0.2 is not installed.
I had the same issue and solved it by adding RUN rm /etc/profile.d/rvm.sh
to my Dockerfile
I've just rebuilt my container today and it's now forcing me to use rvm. Any attempt at bundling puts things into /usr/local/rvm/* - the above workaround no longer appears to work.
//cc @samruddhikhandale Is this potentially related to the migration to https://github.com/devcontainers/features and https://github.com/devcontainers/images ?
Yes, looks related to the migration. We are now setting "GEM_HOME": "/usr/local/rvm/gems/default"
in Ruby Feature here which is why gems get installed in usr/local/rvm/*
with bundling.
Any attempt at bundling puts things into /usr/local/rvm/*
@simmerz Could you try unsetting GEM_HOME
? It should help fix the issue. 😄
Unfortunately, unsetting GEM_HOME
results in the following RUN gem install rails
line failing in the Dockerfile.
That's if I add a line like ENV GEM_HOME ""
above the first gem install
.
If I RUN unset GEM_HOME
it still looks for things in the rvm path when my post create command runs.
I was running the commands from within the container, hence there were no permission issues. However, in your case looks like the dockerfile
and postCreateCommand
both are trying to install gems and fails due to permissions. Also, looks like the dockerfile is run by root
and postCreateCommand
by the remoteUser
. Hence, the errors.
I tried recreating your scenario with ruby
definition and this worked without errors.
ARG VARIANT="3.1-bullseye"
FROM mcr.microsoft.com/vscode/devcontainers/ruby:0-${VARIANT}
ENV GEM_HOME="/home/vscode/.gems" # where the gems will be installed (by default)
ENV GEM_PATH="${GEM_HOME}:${GEM_PATH}" # provides the locations where gems can be found.
RUN gem install rails
# Changing ownership so that the postCreateCommand can install gems with permission issues.
RUN chown -R vscode:vscode ${GEM_HOME} \
&& chmod -R g+w ${GEM_HOME} \
&& find ${GEM_HOME} -type d | xargs -n 1 chmod g+s
...
\\ ...
"postCreateCommand": "gem install rack",
"remoteUser": "vscode"
\\ ...
Gems are installed in specified GEM_HOME
without any errors with the above modifications.
Let me know if this works.
Yes, looks related to the migration. We are now setting "GEM_HOME": "/usr/local/rvm/gems/default" in Ruby Feature here which is why gems get installed in usr/local/rvm/* with bundling.
This leaves the RVM install in an inconsistent state though. A simple cd
will immediately wipe away the GEM_HOME, making it impossible to use any gem install
ed system gems. This is because RVM thinks there's no rubies installed:
@nightpool ➜ /workspaces $ rvm list
# No rvm rubies installed yet. Try 'rvm help install'.
I'm not using devcontainers, but I wound up here after googling ways to temporarily disable rvm
since it was interfering with my usage of direnv
.
After finding nothing, I traced through the rvm source code, and discovered a possible solution to trick rvm:
export __rvm_project_rvmrc_lock=2
This works because rvm uses this environment variable to prevent nesting/recursion when setting up your environment.
Anyways, hope this helps others looking for ways to disable rvm.
Hello, I just started using dev-containers and I noticed that GEM_HOME
is set to /usr/local/rvm/gems/default
as mentioned here already.
How can I successfully install gems in this case?
I've found a workaround is to add sudo chown -R vscode:vscode /usr/local
as my onCreateCommand
The "workaround" that I came up with was to build out a local feature that installs just rbenv
and ruby-build
. See: https://github.com/corgibytes/freshli-cli/blob/8ba51a6b66e74008844e9e738f025591b82f3cd7/.devcontainer/local-features/rbenv-ruby/install.sh
ruby
,ruby-rails
Steps to Reproduce:
ruby-rails
development container definitioncd
into the workspace directory (e.g.cd .
orcd /workspace
from a new Integrated Terminal)rvm
complains about the Ruby version specified in theGemfile
isn't installed, even though the development container specifically has (the correct version of) Ruby installed (see #690).Why are
rbenv
andrvm
installed on Ruby development containers? We can already select the version of Ruby we want installed by using a particular Docker image tag, so there's no need for a Ruby version manager; they generate unnecessary noise and are difficult to remove from the pre-built containers. At the very least, there should be a mechanism to conditionally prevent loading thervm
andrbenv
initialization scripts using an environment variable.