BLD: Refresh gitpod build files #56375
Conversation
gitpod/gitpod.Dockerfile
Outdated
| && rm -rf /var/lib/apt/lists/* | ||
|
|
||
| # Install miniconda | ||
| ENV CONDA_DIR /opt/conda |
There was a problem hiding this comment.
Not opposed but whats the advantage of running conda within Docker versus just using docker for the virtualization?
There was a problem hiding this comment.
I guess to install new packages?
For some reason I can't do stuff like apt install in gitpod.
(sudo doesnt work for me)
In general, I think it's preferred to have stuff installed from conda over pip, too.
There was a problem hiding this comment.
Also on the note of conda versus pip - conda is a pretty big install. Most images try to be small and easy to deploy; I would imagine this makes the image significantly larger than the base
There was a problem hiding this comment.
Are users expected to modify this environment? If so I think installing conda would be nice for ease of use. But since this is for development anyways and not a service having conda here would be OK to me
There was a problem hiding this comment.
Does apt-get install work?
I don't think so?
It's been a while since I last used gitpod. Sorry for the late reply.
There was a problem hiding this comment.
Are users expected to modify this environment? If so I think installing conda would be nice for ease of use. But since this is for development anyways and not a service having conda here would be OK to me
I tend to want to install new packages at least
(e.g. things like a profiler, or trying out different versions of dependencies, like numpydev, etc.)
gitpod/gitpod.Dockerfile
Outdated
| ENV PATH=$CONDA_DIR/bin:$PATH | ||
|
|
||
| # init conda | ||
| RUN conda init |
There was a problem hiding this comment.
Could you combine these RUN statements to reduce the image layers?
| # remote clone | ||
| ARG BASE_CONTAINER="pandas/pandas-dev:latest" | ||
| FROM gitpod/workspace-base:latest as clone | ||
| FROM condaforge/miniforge3:23.3.1-1 |
There was a problem hiding this comment.
One potential issue with using the conda image here is that it is pinned to a specific version. This can lead to Gitpod breaking like in #53685 when the version of conda becomes incompatible with the version of python and other dependencies the environment.yml file.
I think building from the base repo's dockerfile without conda is probably the simpler and easier to maintain approach, as the gitpod instance will update with the base repo's dockerfile. If we were to go down that route, the gitpod folder could actually be deleted entirely, and a .gitpod.yml file is all that is required.
There was a problem hiding this comment.
The reason I switched to conda from Docker is that docker doesn't provide a way to install packages (I don't think there is any sudo in the gitpod container - at least apt-get/pip don't work for me).
I think Docker might also have the same problem since the packages installed will be cached and won't update unless you recreate the gitpod instance.
I avoid the problem here by updating the conda packages on install based on the environment.yml. I'm happy to switch back to Docker if there's a way to do the same there.
There was a problem hiding this comment.
I think most Docker images do not include sudo. What error were you seeing when doing something like apt-get update && apt-get install -y <some_package>?
There was a problem hiding this comment.
Something like this
gitpod@lithomas1-pandas-1tcur93d5vv:/workspace/pandas$ apt install build-essential
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: Permission denied)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), are you root?
gitpod@lithomas1-pandas-1tcur93d5vv:/workspace/pandas$ sudo apt install build-essential
bash: sudo: command not found
There was a problem hiding this comment.
Hmm strange...and you are running that between the
USER root
....
USER gitpodcommands in the image right? I think anything in between those should be running under the root user account
There was a problem hiding this comment.
No, this is when the workspace is started up, not in the Dockerfile.
There was a problem hiding this comment.
It looks like the Dockerfile intentionally runs under a non-priviledged user. So you'd have to install system libraries before that or remove the USER gitpod statement in gitpod.Dockerfile (no idea if that is a good idea for gitpod or not)
|
This pull request is stale because it has been open for thirty days with no activity. Please update and respond to this comment if you're still interested in working on this. |
|
Going to close to clear the queue, but feel free to reopen if you want to circle back |
doc/source/whatsnew/vX.X.X.rstfile if fixing a bug or adding a new feature.