[BUG] /lsiopy folder & 'VIRTUAL_ENV': '/lsiopy': Why included in image?

[ManiMatter]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

The vscode image comes with a folder called "/lsiopy" and a enviornment variable 'VIRTUAL_ENV': '/lsiopy'..

My take is that these are two remnants of the Jenkins file. Since the vscode image does not actually have a python binary installed, I am not sure these two serve any purpose and I wonder why they are included in the image.

docker-code-server/Jenkinsfile

Line 269 in 2f251a6

python3 -m venv /lsiopy && \

The reason I am bringing this up is because the VIRTUAL_ENV variable has caused an issue for me, since the application "poetry" is also using the same variable, and I hadn't been aware that codeserver already had set a value for it.

Expected Behavior

If there is no use of the /lsiopy folder and the associated environment variable post jenkins installation they should not be included in the image.

Steps To Reproduce

1. Spin up a fresh codeserver container
2. Check the presence of folder "/lsiopy"
   test -d /lsiopy && echo "Directory exists" || echo "Directory does not exist"

• Will say "Directory exists" and expected would be "Directory does not exist"

3. Check the presence of env variable
   echo $VIRTUAL_ENV

• Will return "/lsiopy" and expected would be nothing

CPU architecture

x86-64

Docker creation

vscode:
    <<: *common-keys-core
    image: lscr.io/linuxserver/code-server:latest
    container_name: vscode
    ports:
      - 8443:8443
    environment:
      <<: *default-tz-puid-pgid
      SUDO_PASSWORD: $VSCODE_SUDO_PW
    volumes:
      - $DOCKERDIR/own_coding/vscode/:/vscode
      - $DOCKERDIR:/docker
      - /var/run/docker.sock:/var/run/docker.sock
      - /:/host:ro # for cloudbackup development
    security_opt:
      - no-new-privileges:false
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.vscode-rtr.entrypoints=https"
      - "traefik.http.routers.vscode-rtr.rule=Host(`vscode.$DOMAINNAME_CLOUD_SERVER`)"
      - "traefik.http.routers.vscode-rtr.tls=true"
      - "traefik.http.routers.vscode-rtr.middlewares=chain-oauth@file"
      - "traefik.http.routers.vscode-rtr.service=vscode-svc"
      - "traefik.http.services.vscode-svc.loadbalancer.server.port=8443"

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[aptalca]

Jenkinsfile line is unrelated
We create that venv folder and set the env var in the baseimage because pip no longer uses system folder to install things into.

All of our images that utilize python activate that venv.

You can either override that env var, or choose to use that path for the venv. For the latter, you would have to activate the venv at that path (the mod may have to do that as well).

[ManiMatter]

Thank you for the follow up.

Just so that I get it right: when I run codeserver, python is not installed (and therefore python virtual env cant be active) but the VIRTUAL_ENV-variable is set.

If my understanding is correct, my next question: does that make sense? Isn‘t the VIRTUAL_ENV there to flag that the venv is active (and at what path)?

Of course, I can unset the variable myself, but (and I‘m not an expert here) if VIRTUAL_ENV should indicate whether the venv is active (ENV set = venv active) but in the image it‘s set and the venv is not active, should this ENV not be removed from the image (since suggesting a misleading status)?

[aptalca]

Any container that installs/uses python has the venv activated. On other containers it doesn't matter if that env var is set or not because there is no python to begin with.

Even our package install mod is set to activate the venv if python and/or pip packages are installed.

The issue you're having is that the poetry mod does not activate the venv. It's a third party submitted mod. You can open an issue or a PR in its repo.

[ManiMatter]

I am not taking about a mod. I run the codeserver image and on the terminal install python as well as poetry.

I did raise it with them; their response, however, is that the env VIRTUAL_ENV is the signal to tell that the venv is active.

the only thing that activating a virtual environment does is to set that variable and tweak the path. A virtual environment is active exactly when VIRTUAL_ENV says so: the meaning of that variable is "this is the active virtual environment".

My take from your response is that your usage is different. You use VIRTUAL_ENV to say „here is where the virtual env ought to go“ but the presence of VIRTUAL_ENV says nothing about whether said venv is active or not.

I am not an expert but I‘d say we have here two different notions what VIRTUAL_ENV represents (codeserver: just a dir, poetry: dir and active status). Is there an agreed definition what that ENV expresses?

If with status, then I think codeserver should not include the VIRTUAL_ENV if venv not active.
If without status, then poetry should try activating the venv
If no agreed notion exists, I‘ll unset the ENV myself (or activate the venv it)

[aptalca]

We have mods for that reason. They install the necessary packages and prepare the environment as necessary.

We don't recommend or support manually installing packages inside the container as they also get wiped during container recreation.

[ManiMatter]

Thank you for clarifying

[alanjds]

Of course, I can unset the variable myself, but (and I‘m not an expert here) if VIRTUAL_ENV should indicate whether the venv is active (ENV set = venv active) but in the image it‘s set and the venv is not active, should this ENV not be removed from the image (since suggesting a misleading status)?

@aptalca Is this behavior documented somewhere else than this Gh issue?

Asking because took me a lot of time to understand why Rust ESP-IDF package was not installing correctly and saying that "a virtualenv was already installed".

For most images, this detail may be irrelevant. But for development tools, like VSCodium or OpenVSCode-Server, this "always-activated virtualenv" detail is very important.

And more than that: How do I disable this behavior? Is just about putting an unset VIRTUAL_ENV line on .bashrc, or something more involved is needed?

[aptalca]

It's something forced on everyone by recent versions of pip. Pip devs don't want people to install packages next to system packages. They want you to install them in a venv.

So whenever we install packages via pip (whether build time via the dockerfile or runtime via our package install mod) we first create a venv at /lsiopy and install in there. Parts of that workflow are in our baseimages.

I have no idea what the rust esp-idf package is or how you're installing it, so I can't comment on the failure.

[alanjds]

no idea what the rust esp-idf package is or how you're installing it,

esp-rs is a framework by Expressif, (the makers of ESP32, ESP8266 and other ESP* chips) used in IoT. Usually you will code for your microcontroller in C/C++, Python or Node.js. But you can also code in Rust with esp-rs.

The tooling installation is involved but automated. However it assumes that you are running in system' Python, because it is the standard. And in one step it creates its own virtualenv to host some tools and packages, to mess not with the system Python, of course.

If you run the installation within a Virtualenv it breaks :)
But you will not assume that you are always using a virtualenv, correct? Usually a virtualenv activation changes the shell prompt.

To circumvent our situation, I had to simple change some internal script from calling python to call /usr/bin/python and stuff worked.

But to get to a point of understanding why it was failing...