Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Python Path Resolution Ignores Activated Virtual Environments on Windows #4234

Open
Molier opened this issue Jan 17, 2025 · 0 comments

Comments

@Molier
Copy link

Molier commented Jan 17, 2025

Version

4.0.6821

Description

The Azure Functions Core Tools' Python path resolution logic has significant issues on Windows that make it difficult to use virtual environments reliably. The current implementation prioritizes global Python installations and the Python Launcher for Windows (py.exe) over activated virtual environments, causing modules installed in the virtual environment to be unavailable during local function execution.

Steps to reproduce

Current Behavior

When running func host start, the tool ignores both:

  • The currently activated virtual environment
  • The azureFunctions.pythonVenv setting in VSCode settings.json

The path resolution function (GetEnvironmentPythonVersion()) searches for Python in this order:
csharpCopy1. Environment variable "languageWorkers:python:defaultExecutablePath"
2. Windows Python Launcher ("py")
3. "python3"
4. "python"
5. Specific versions (python3.6-python3.12)

On Windows, this causes issues because:

The Windows Python Launcher ("py") is checked before virtual environment paths
The resolution order doesn't consider the active virtual environment's priority
No logging of which Python executable path was actually selected

Impact

  • Developers can't use isolated virtual environments effectively
  • Installed packages in virtual environments are not found
  • Development/production parity issues
  • Workarounds (like copying python.exe to py.exe in venv) are hacky and fragile

Proposed Solution

Modify the Python path resolution logic to:

var versions = new List<WorkerLanguageVersionInfo>
{
    await pythonGetVersionTask,  // Check "python" first (catches activated venv)
    await python3GetVersionTask,
    await pyGetVersionTask,      // Move Windows Launcher lower in priority
    // ... rest of version checks
};
  1. Add verbose logging to show:
  • Full path of selected Python executable
  • All candidates considered and their paths
  • Why each candidate was accepted/rejected
  1. Respect the VSCode azureFunctions.pythonVenv setting by adding it to the resolution order

Steps to Reproduce

  1. Create new Python Azure Function project
  2. Create virtual environment: python -m venv .venv
  3. Activate virtual environment: .venv\Scripts\activate
  4. Add custom package to requirements.txt
  5. Install requirements: pip install -r requirements.txt
  6. Run func host start --verbose
  7. Observe that global Python is used instead of venv Python

##Environment

OS: Windows 11
Azure Functions Core Tools: 4.x
Python: 3.11
VSCode: Latest

Related Issues

#3042
#2041

Additional Context

This is a blocker for Python development with Azure Functions on Windows, as it prevents reliable local development with virtual environments. The current workarounds (copying executables, setting environment variables) are not suitable for production environments or team development scenarios.
/cc @vrdmr @ejizba

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

No branches or pull requests

1 participant