Skip to content

Identical, meaningless suffixes for same-name global interpreters in Environment Managers #1893

Description

Problem: When environments in the Environment Managers view share a name, the view adds a suffix to tell them apart (#1196). For global interpreters, that suffix is a path segment that doesn't identify the interpreter: the user name, AppData, bin, usr or opt. Interpreters in the same folder always get the same suffix, so they still can't be told apart.

Environment: Windows 11, VS Code 1.140.0, Python Environments main @ 52f6ace with PET main; uv 0.12.17 with ~/.local/bin on PATH.

Before: three Global entries all read Python 3.13.15 kanadig (the Windows user name). They are uv's python.exe, python3.exe and python3.13.exe launchers in C:\Users\kanadig\.local\bin:

Environment Managers: three "Python 3.13.15 kanadig" entries under Global

Suffixes the view computes for other global interpreters:

Interpreter Suffix
C:\Users\<user>\.local\bin\python.exe <user>
C:\Users\<user>\.local\bin\python3.13.exe <user>
C:\Users\<user>\AppData\Local\Python\pythoncore-3.14-64\python.exe AppData
C:\Users\<user>\AppData\Local\Python\pythoncore-3.14t-64\python3.14t.exe AppData
/usr/bin/python3.13 bin
/usr/bin/python3.13t bin
/usr/local/bin/python3.13 usr
/opt/homebrew/bin/python3.13 opt

Same-name global interpreters are common. The uv launchers above show up today (the duplicate discovery itself is tracked in microsoft/python-environment-tools#567). Regular and free-threaded builds share a version: Fedora's regular /usr/bin/python and free-threaded /usr/bin/python3.13t would both read Python 3.13.13 bin once microsoft/python-environment-tools#569 is fixed.

Cause: computeDisambiguationSuffixes uses getEnvironmentParentDirName for every environment. That helper assumes a venv layout (<project>/<venv>/bin|Scripts/python → <project>). For an interpreter that sits directly in a bin or install folder, it climbs past the folder that identifies it.

Suggested fix: Use the part of the path that differs within the group: the executable's folder for environments that aren't venvs, and the executable name when the folders are the same (python3.13 vs python3.13t). Keep the project folder name for venvs.

Steps to verify fix:

  1. On Windows with uv's ~/.local/bin on PATH, or on Linux with python3.13 and python3.13-freethreading installed, open the Environment Managers view and expand Global.
  2. Verify that same-name interpreters have different suffixes that identify them (for example the executable names).
  3. Verify no suffix is the user name, AppData, bin, usr or opt.
  4. Verify two .venv (3.12) environments in different projects still show their project folder names.
  5. Verify environments with unique names have no suffix.

Found by Copilot

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

Metadata

Metadata

Labels

bugIssue identified by VS Code Team member as probable bugtriage-needed

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions