azure-functions-core-tools icon indicating copy to clipboard operation
azure-functions-core-tools copied to clipboard

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

Open Molier opened this issue 10 months ago • 2 comments

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

Molier avatar Jan 17 '25 09:01 Molier

Any updates here? This issue has been open for 5 months with no activity, and the behavior has been reported since 2022: https://github.com/Azure/azure-functions-core-tools/issues/3042

afickley5 avatar May 12 '25 13:05 afickley5

Same story on Mac

scotts-chrysalis avatar Jun 05 '25 00:06 scotts-chrysalis