Skip to content

Support setting environmental variables for the test runner #17171

Open

Description

Discussed in #16760

Originally posted by JohnSpeno July 22, 2021
In the microsoft-python discord, I asked:

Is there a way to have the DYLD_LIBRARY_PATH environmental variable set for the built-in test discovery/runner? I set it up for debugging + debugging tests via launch.json but that isn't integrated with the testing UI which is what I hope to use. This is on macOS 11.4 (big sur) with vscode Version: 1.58.2 and all extensions up to date. Thanks. Note: launching using code . in a shell with the env set properly apparently doesn't propagate DYLD_LIBRARY_PATH as a macOS safety feature these days.

And Brett Cannon said:

There currently isn't, but if you could open a feature request at https://github.com/microsoft/vscode-python that would be appreciated!

so I am doing that.

I find getting environmental variables set for various parts of VS Code to be difficult currently. I can work around that by running code . in my pre-configured shell environment to launch vscode on my project and it mostly works. The DYLD_LIBRARY_PATH might be a special case due to hardened runtimes on macOS but I'm not exactly sure.

Thanks.

Activity

  1. brettcannon commented on Sep 1, 2021

    @brettcannon
    MemberAuthor

    Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 5 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.

  2. WayneLambert commented on Sep 3, 2021

    @WayneLambert

    Hi,

    I have noticed a couple of issues relating to the collection of environment variables using VS Code and pytest for a Django project which uses multiple environment files.

    This is still the case since the release of VS Code 1.60 and with the newest version of the Python extension installed (both released on 02-Sep-21).

    The first issue can be described as the difference of running the test suite locally as opposed to running it within remote Docker containers.

    For a debugging configuration for normal project code within VS Code, you get the option of setting the PathMappings array/object within your launch.json file to something like this.

            ...
            {
                "name": "Django: Docker",
                "type": "python",
                "request": "attach",
                "host": "localhost",
                "django": true,
                "port": 8890,
                "justMyCode": false,
                "internalConsoleOptions": "openOnSessionStart",
                "pathMappings": [
                    {
                        "localRoot": "${workspaceFolder}",
                        "remoteRoot": "/code"
                    }
                ],
            },
            ...

    This enables the debugger to understand your project root configuration both locally and remotely.

    However, unless I am mistaken (and I have searched documentation, issues, release notes, Googled, etc), there doesn't seem to be the ability to set your remote root in the same way to facilitate test discovery for remote development.

    Within a non-standard Django project, you might have many environment variable files. A Docker setup means that these can all be loaded into the environment when the containers are brought up because you can list multiple environment variable files using the env_file option within a Docker compose file. See snippet below.

        ...
    
        env_file:
          - dev.env
          - .env
          - postgres.env
    
        ...

    Running pytest within the Docker container using the CLI will run all of the tests, set the root directory (which is naturally the remote root) and have access to all of the environment variables.

    $ docker-compose exec web pytest

    Running pytest locally using the CLI will only successfully run the tests that do not need the environment variables from the secondary environment files (e.g dev.env or postgres.env in the above example). This often poses a problem with tests that acccess a test database since database config and environment variables are often separated into their files to use different databases.

    $ pytest
    

    Someone who runs their Django (or Python) project locally and uses only the one environment file will be able to use the pytest discovery currently within VS Code, however people that use either multiple environment files or develop remotely (e.g. using Docker) will not.

    For those developing locally, they might be able to use multiple environment files if the setting python.envFile within your workspace was adjusted to accept an array of files instead of just the one.

    For those developing remotely, they might need something similar to the aforementioned pathMappings object that is currently used within a launch.json configuration. I would imagine that developers would want to manage the loading of environment variables by their Docker/Docker compose setups rather than listing the environment files again within VS Code workspace configuration.

  3. brettcannon commented on Nov 1, 2021

    @brettcannon
    MemberAuthor

    Thank you to everyone who upvoted this issue! Since the community showed interest in this feature request we will leave this issue open as something to consider implementing at some point in the future.

    We do encourage people to continue 👍 this issue as it helps us prioritize our work based on what the community seems to want the most.

  4. veedeo commented on Dec 21, 2021

    @veedeo

    It would be great to have a configuration manager and selector for Test runner. So we will be able to run tests on different environments.
    Currently, it is the last feature that holds my team to switch from WebStorm

  5. hynek commented on Apr 12, 2023

    @hynek

    To add a humble perspective: I can't use VS Code's code runner / debugger at work for this simple reason. For our database driver to work, I need to pass DYLD_LIBRARY_PATH into the process and the way VS Code runs it, it gets filtered out (this is a bit of a tricky problem, see Surprising Consequences of macOS’s Environment Variable Sanitization).

    So no amount of env files or whatever might work on the CLI is helpful here at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

area-testingcommunity askFeature request that the community expressed interest infeature-requestRequest for new features or functionalityneeds proposalNeed to make some design decisions

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions