python-setup: Don't allow Poetry to make venv in project

CHANGELOG.md

@@ -3,6 +3,7 @@
 ## [UNRELEASED]
 
 - Add a step that tries to upload a SARIF file for the workflow run when that workflow run fails. This will help better surface failed code scanning workflow runs. [#1393](https://github.com/github/codeql-action/pull/1393)
+- Python automatic dependency installation will no longer consider dependecy code installed in venv as user-written, for projects using Poetry that specify `virtualenvs.in-project = true` in their `poetry.toml`. [#1419](https://github.com/github/codeql-action/pull/1419).
 
 ## 2.1.35 - 01 Dec 2022
 

python-setup/auto_install_packages.py

@@ -33,10 +33,17 @@ def _check_output(command, extra_env={}):
 
 def install_packages_with_poetry():
 
-    # To handle poetry 1.2, which started to use keyring interaction MUCH more, we need
-    # add a workaround. See
-    # https://github.com/python-poetry/poetry/issues/2692#issuecomment-1235683370
-    extra_poetry_env = {"PYTHON_KEYRING_BACKEND": "keyring.backends.null.Keyring"}
+    extra_poetry_env = {
+        # To handle poetry 1.2, which started to use keyring interaction MUCH more, we need
+        # add a workaround. See
+        # https://github.com/python-poetry/poetry/issues/2692#issuecomment-1235683370
+        "PYTHON_KEYRING_BACKEND": "keyring.backends.null.Keyring",
+        # Projects that specify `virtualenvs.in-project = true` in their poetry.toml
+        # would get the venv created inside the repo directory, which would cause CodeQL
+        # to consider it as user-written code. We don't want this to happen. see
+        # https://python-poetry.org/docs/configuration/#virtualenvsin-project
+        "POETRY_VIRTUALENVS_IN_PROJECT": "False",
+    }
 
     command = [sys.executable, '-m', 'poetry']
     if sys.platform.startswith('win32'):

python-setup/tests/poetry/requests-3/poetry.toml

@@ -0,0 +1,2 @@
+[virtualenvs]
+in-project = true