Environment Variables during remote Debug

Technical Support
, , , ,
1

We have a project that requires environment variables, also during debug. Unfortunately, I was not able to set any variables for the remote debugging launch configuration.

I created a minimal demo project using python. There are only two modifications from the template:

  1. The main.py reads and prints an env variable.
if __name__ == "__main__":
    myname = os.getenv("MY_NAME")
    print(f'Hello {myname}')
  1. The docker-compose.yml tries to set it_
services:
  pytest-debug:
    environment:
      MY_NAME: FOO
    build:
      context: .
      dockerfile: Dockerfile.debug
    image: ${LOCAL_REGISTRY}:5002/pytest-debug:${TAG}
    ports:
      - ${DEBUG_SSH_PORT}:${DEBUG_SSH_PORT}
      - ${DEBUG_PORT1}:${DEBUG_PORT1}

  pytest:
    environment:
      MY_NAME: FOO
    build:
      context: .
      dockerfile: Dockerfile
    image: ${DOCKER_LOGIN}/pytest:${TAG}

When running the program locally, it works as expected reading and printing the env variable. Building the docker image and deploying it through a docker-compose.yml similar to the one above also works.

However, when I start the application using the RUN AND DEBUG button, Torizon arm64 configuration, the environment variables in the docker-compose.yml above are simply ignored and the program prints “Hello None”.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Environment Variables in Debug Mode

When debugging with the Torizon IDE extension, environment variables defined in docker-compose.yml are not automatically passed to the debug container. The debug configuration uses the launch.json file to manage the debugging process (1).

Solution: Configure Environment Variables in launch.json

To set environment variables for debugging, you need to modify the launch.json file located in the .vscode folder of your project (2). The launch.json file stores the configurations required to launch the application with the debugger (1).

  1. Locate and open the launch.json file in your .vscode folder (1)
  2. Find the configuration for your target architecture (e.g., “Torizon arm64”) (1)
  3. Add an env section to define your environment variables

Here’s how your launch.json configuration should look:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Torizon arm64",
            "type": "python",
            "request": "launch",
            "program": "${workspaceFolder}/main.py",
            "env": {
                "MY_NAME": "FOO"
            },
            "args": [],
            // ... other configuration options
        }
    ]
}

Why This Happens

The debug container is defined by Dockerfile.debug and is deployed and executed on the target device when debugging applications (3). Since this container is built on the host machine and executed on the SoM, the environment variables from docker-compose.yml are not automatically transferred to the debug session (3).

The Torizon IDE extension manages the creation and running of the debugger container, and uses the launch.json file to store the configurations required to launch the application with the debugger (1).

Alternative Approach

You can also define environment variables directly in your debug container by modifying the Dockerfile.debug file to include ENV statements, but using launch.json is the recommended approach for debugging scenarios as it provides more flexibility.

Best regards, Toradex AI Assistant.

3

Greetings @amueller,

I was able to reproduce what you observed here.

It seems this is unique to the debugging method used here. For remote debugging a virtual environment (venv) is used. It seems the environment variables are not being preserved in this case.

If I execute the Python app as is inside the container, then it properly picks up the environment variable as expected. So it seems to only happen with remote debugging. Local debugging and release configurations seem to work fine.

I will bring this up with our extensions team.

Best Regards,
Jeremias

4

Okay after discussing internally, it seems the debug method used here is a bit limited in terms of setting environment variables. However, this is still possible by setting the variable in the Dockerfile.debug file instead.

I tried this and now the Python application gets the expected value for the environment variable.

Best Regards,
Jeremias

5

Hello Jeremias,
thanks for looking at this at such short notice!

To start chronologically, the solution suggested by the AI doesn’t seem to work since it concerns a different launch configuration (“type”: “debugpy” instead of “python”). When I try to add an env section, the syntax checker tells me “Property env is not allowed here”. Debugging starts, but the env variable is ignored.

Your solution, defining the env variables in the Dockerfile.debug works - I hadn’t thought about that since I expected variables defined there would only be valid for the build process - thanks!

For completeness sake, I found another way of getting it to work: By modifying the task “rsync-torizon-generic” in tasks.json and including an .env file in the copy process, the variables defined there are also available for the debug process. However, this requires using the dotenv package in python, so the main.py file becomes:

#!python3
import os
from dotenv import load_dotenv

if __name__ == "__main__":
    load_dotenv()
    myname = os.getenv("MY_NAME")
    print(f'Hello {myname}')

Here is the addition in tasks.json:

"label": "rsync-torizon-generic",
            "detail": "",
            "hide": true,
            "command": "rsync",
            "type": "process",
            "args": [
                "-P",
                "-av",
                "-e",
                "ssh -p ${config:torizon_debug_ssh_port} -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null",
                "${workspaceFolder}/src",
                "${workspaceFolder}/.env", // <------ add this line!
                "${config:torizon_run_as}@${config:torizon_ip}:${config:torizon_app_root}/"
            ], ... }

This method has the advantage that one can use the same .env file for local and remote debugging, however I am careful when making changes to predefined files. Could you comment on that?

Thanks,

Andreas

6

Could you comment on that?

Well as long as it fulfills your requirements, then I see no issue.

We just suggested the Dockerfile method because it was the first we thought of and seemed simple enough. Though this is all only needed because of the limitations of the debug method used here in VSCode. For an actual release configuration setting the environment variable in the docker-compose file will work.

Best Regards,
Jeremias

7

So we two methods that work for debug, we will discuss internally what suits us best. I believe we can mark this issue as resolved.

Thank you,

Andreas

8

Glad we were able to resolve this!