Python packages not persisting between workspace restarts

[kevin-ci]

Bug description

Packages installed with Pip are not persisting between workspace restarts.

Steps to reproduce

Open the following in gitpod: https://github.com/kevin-ci/gitpod-bug-demo

Use pip3 install -r requirements.txt to install the requirements. Then run pip3 freeze to ensure they're installed.

Manually stop and restart the workspace. When it restarts, run pip3 freeze again. The installed packages (Django in this case) will be gone. A bunch of default packages will still be present.

Workspace affected

No response

Expected behavior

The packages persist between restarts, as they used to.

Example repository

No response

Anything else?

This seems to be related to an issue I raised the other day: #7064

[quental96]

Opened a more detailed issue on the subject here and also in the gitpod community.

[lechien73]

Thanks @quental96 - please also link #7064 to the discussion due to the bloatware libraries that are now installed.

[JanKoehnlein]

As of now, Gitpod only persists the /workspace folder between sessions. You might want to install the packages using a custom dockerfile or teach pip3 to use a subdir under /workspaces (https://stackoverflow.com/questions/2915471/install-a-python-package-into-a-different-directory-using-pip)

[lechien73]

As of now, Gitpod only persists the /workspace folder between sessions.

Is this new behaviour? @JanKoehnlein

Pip modules always used to be stored under the /workspace directory. Could you offer some feedback as to the huge amount of superfluous Python libraries that are now installed by default too? If this is the new default behaviour, then it seems that the only option for us is to teach students how to use virtual environments, in which case, we may as well just teach them VSCode locally.

[kevin-ci]

@JanKoehnlein I really don't understand the reasoning behind these changes, or apathy shown in this thread.

The Gitpod homepage says:

Spin up fresh, automated dev environments for each task, in the cloud, in seconds.

The workspaces can hardly be called fresh if they're now bloated with so many packages that it breaks Heroku deployments, and the lack of package persistence between restarts has now made Gitpod objectively worse than Codespaces, its main competitor. I don't see how you can brush this off as "this is how it works" when even the sample prebuilds provided are no longer working: #7078

[JanKoehnlein]

Sorry for the late reply. The persistence of the workspace folder only has always been this way. I suspect something has changed in the setup of the workspace-full image such that python packages are no longer persisted there.

/cc @ghuntley could you try to find out what's going wrong here?

You should be able to work around this by switching to an earlier workspace image in your .gitpod.yml file

image: gitpod/workspace-full:<tag>

See https://hub.docker.com/r/gitpod/workspace-full/tags for tags.

[lechien73]

Thanks @JanKoehnlein - this seems to half work. I used one of the previous commits (commit-8fc141dbdd92030a435ead06617c6d37651d8312) and the build worked fine with none of the bloat; however, on stopping and restarting the workspace, the bloatware appears again. I'm going to try with an older commit and see what happens.

[awmath]

The issue most likely lies with this commit gitpod-io/workspace-images@507a50a
Removing PIP_USER=yes makes PYTHONUSERBASE=/workspace/.pip-modules ineffective by installing all packages under /home/gitpod/.pyenv/.... which is not persistent between WS restarts.

[lechien73]

Can probably merge this with the discussion here: #7064

[tiamot]

@lechien73, I think this is a different issue from 7064. Issue 7064 is focused on removing unwanted packages that are installed in the workspace-full image (removing bloat).

I think the issue described by @kevin-ci is more focused on packages being installed in one workspace, and then not persisting to another.

I have a similar problem as the op. My issue is when I setup my environment to have init do pip installs, those installed packages work fine until I attempt to use pre-builds. Once I turn on prebuild for a repo things stop working.

To recreate:

1. create a new repo in gitlab
2. launch gitpod from repo
3. gp init
4. Set init: pip install
5. turn on prebuild
6. launch a new gitpod and run pip freeze (package installed by init is not in the workspace)

Similar to #7110