fix: hide Python activity bar icon in non-Python workspaces

[Mohit Yadav (mohityadav8)]

Fixes microsoft/vscode-python#26015

Added context key python-envs.workspaceHasPython via findFiles + FileSystemWatcher. ANDed into when clauses of the activitybar container and both views.

[Eduardo Villalpando Mello (edvilme)]

Thanks for your contributions!
LGTML :)

[Mohit Yadav (mohityadav8)]

hi @edvilme Both CI failures are unrelated to this PR's changes:

1. Check for changed files (package-lock.json)
The package.json edits in this PR only modify the contributes section (VS Code metadata-- viewsContainers and views when clauses).No npm dependencies were added or changed, so package-lock.json does not need updating . Could a maintainer add the skip package*.json label to pass this check?

2. Integration test failure (pythonProjects.integration.test.js:150)

The failure is:
AssertionError: Retrieved environment should match set environment

'Python 3.14.6.final.0-j5ae0pzs6ek'
'Python 3.14.6.final.0-m8ni2jdqggb'
This is a pre-existing flaky test comparing non-deterministic environment hash suffixes. It is not triggered by any code in this PR -- the new file (workspacePythonContext.ts) and the changes to extension.ts and package.json have no interaction with environment resolution or the project manager.

[Stella Huang (StellaHuang95)]

The PR hides the activity-bar icon unless this context key is true:

python-envs.workspaceHasPython

That key is not defined initially. It only gets set after the extension’s  activate()  function runs:

registerWorkspacePythonContext(context.subscriptions);

However,  package.json currently activates the extension only when VS Code opens a Python-language document:

"activationEvents": [ "onLanguage:python" ]

This creates a circular dependency:

1. The extension must activate to detect Python files and set the context key.
2. The activity-bar icon is hidden until that key is set.
3. A hidden view cannot be opened to activate the extension.
4. If no  .py  file is opened,  onLanguage:python never activates the extension.

Example

A user opens a repository containing:

my-project/
├── pyproject.toml
├── requirements.txt
└── README.md

The repository is clearly a Python project, but the user has not opened a  .py  file yet.

Expected: The Python activity-bar icon appears because pyproject.toml  identifies the workspace as Python.

Actual: The extension does not activate, so it never searches for  pyproject.toml . The context key remains unset, and the icon stays hidden.

[Mohit Yadav (mohityadav8)]

Good catch. Fix is to add workspaceContains activation events to package.json so the extension activates even before a .py file is opened:

"activationEvents": [
"onLanguage:python",
"workspaceContains:**/*.py",
"workspaceContains:pyproject.toml",
"workspaceContains:requirements.txt",
"workspaceContains:Pipfile",
"workspaceContains:setup.py",
"workspaceContains:mspythonconfig.json",
"workspaceContains:.venv",
"workspaceContains:.conda"
]

This breaks the circular dependency - extension activates when any marker file is present in the workspace, sets the context key, and the icon appears without needing a .py file open first.

[Stella Huang (StellaHuang95)]

Is this only searching inside open workspaces folders. What if user opens a standalone Python file without opening the folder?

[Mohit Yadav (mohityadav8)]

findFiles only searches workspace folders, so standalone file case is missed. Will add a fallback check on open text documents:

async function refresh(): Promise<void> {
    const hits = await findFiles(MARKER_GLOB, EXCLUDE, 1);
    if (hits.length > 0) {
        await executeCommand('setContext', PYTHON_WORKSPACE_KEY, true);
        return;
    }
    const hasPythonDoc = workspace.textDocuments.some(
        (doc) => doc.languageId === 'python',
    );
    await executeCommand('setContext', PYTHON_WORKSPACE_KEY, hasPythonDoc);
}

And subscribe to onDidOpenTextDocument in registerWorkspacePythonContext.

[Stella Huang (StellaHuang95)]

Is EXCLUDE only passed to findFiles() but not the createFileSystemWatchter? Does that mean the watcher still listens for every .py  file created or deleted under site-packages? I am a bit worried about the perf here.

[Mohit Yadav (mohityadav8)]

Correct-- createFileSystemWatcher has no exclude parameter in the VS Code API, so it fires for site-packages too. Fix is to filter in the event handlers:

const EXCLUDE_RE = /[\\/](node_modules|\.git|site-packages)[\\/]/;

watcher.onDidCreate((uri) => { if (!EXCLUDE_RE.test(uri.fsPath)) void refresh(); }),
watcher.onDidDelete((uri) => { if (!EXCLUDE_RE.test(uri.fsPath)) void refresh(); }),

This avoids unnecessary refresh() calls from excluded directories.

[Eduardo Villalpando Mello (edvilme)]

Hello Mohit Yadav (@mohityadav8) thanks for following on with the reviews. I think there is still one unresolved issue and a merge conflict before we can take another look :)

[Mohit Yadav (mohityadav8)]

Hello @mohityadav8 thanks for following on with the reviews. I think there is still one unresolved issue and a merge conflict before we can take another look :)

Solve conflict can u please share what's the issue I forgot to see in workflow

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.