Open baolsen opened 3 weeks ago
I have got the same problem, both for just building a package and building layers. Only difference is that in my case python path is: C:\Program Files\Python311\python.exe
And I am using:
compatible_runtimes = ["python3.12", "python3.11"]
runtime = "python3.11" # required to force layers to do pip install
Happy to assist with any testing or more debug.
mklink workaround from past solution won't apply to me as that requires admin permissions which I don't have on my workstation.
Description
When on Windows and building a Python package in a Virtual Env, the
package.py
script produces an error such as below:The error message is descriptive and the reason and workaround is as described in #487.
Basically, within the virtual environment in Windows there is
python.exe
but notpython3.10.exe
. For some reason on Linux there is apython3.10
which therefore prevents this issue, but not on Windows.Versions
Module version [Required]:
~> 7.4
specifically 7.4.0Terraform version: 1.6.3
Provider version(s):
Reproduction Code [Required]
Simplified code below.
Steps to reproduce the behavior:
In the Python installation dir observe there is "python.exe" and "python3.10.exe"
python3.10 -m venv .venv
orpython -m venv .venv
etc This is done as I have multiple Python versions installed and want to be sure the right one is available for testing and development.When using VSCode the venv is automatically activated.
.venv/Scripts
:There is
python.exe
but notpython3.10.exe
.Expected behavior
The
package.py
script should work as there is a correct version of Python in the path. It is not calledpython3.10
instead it is called simplypython
Actual behavior
Terminal Output Screenshot(s)
Unable to upload as the GitHUb upload URLs are blocked by corporate firewall.
Additional context
I think requiring the exact "python3.10" on the path as a preference is fine, as this works fine on Linux and is more explicit. But there should be a fallback added to check "python" exists and it has a required version, then proceed with the build (maybe add a warning).
Alternatively - probably better solution - a parameter added to the Terraform module to make it possible for a user to specify the path to the Python command themselves (and avoid the
package.py
maybe assuming the wrong thing)