You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
varversions=newList<WorkerLanguageVersionInfo>{awaitpythonGetVersionTask,// Check "python" first (catches activated venv)awaitpython3GetVersionTask,awaitpyGetVersionTask,// Move Windows Launcher lower in priority// ... rest of version checks};
Add verbose logging to show:
Full path of selected Python executable
All candidates considered and their paths
Why each candidate was accepted/rejected
Respect the VSCode azureFunctions.pythonVenv setting by adding it to the resolution order
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
The text was updated successfully, but these errors were encountered:
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 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
Proposed Solution
Modify the Python path resolution logic to:
Steps to Reproduce
##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
The text was updated successfully, but these errors were encountered: