[osgeo4w-dev] [osgeo4w] #814: stdlib venv's broken on new Python 3.9.18

[OSGeo4W]

#814: stdlib venv's broken on new Python 3.9.18
-----------------------+---------------------------------------
Reporter:  akominlsfi  |      Owner:  osgeo4w-dev@…
    Type:  defect      |     Status:  new
Priority:  critical    |  Component:  Package
 Version:              |   Keywords:  python, stdlib, venv, dll
-----------------------+---------------------------------------
 After Python update to 3.9.18, stdlib venv module usage is broken.

 This may be due to venv .exes being the same exact exe as the original,
 copied in
 [https://github.com/jef-n/OSGeo4W/commit/c290dc6c5d7d2ab4cbe0a5bb256d05839189633c
 #diff-dc4b1e47c00b8f477e2a83335db08806820d54063a982eedf8c4ac205ec7ac88R83
 this line]? Not sure if the compilation even outputs
 [https://github.com/python/cpython/commit/1c3de541e64f75046b20cdd27bada1557e550bcd
 #diff-26115511cc004fd83fde0fa4e7fe691a99ccdd351aa7b7ec2a8079444e962cceR25
 these venvlauncher exes], which I assume would be needed in that directory
 instead of the original exes?

 Is using the bundled Python standalone without any PATH/env manipulation
 even a supported use case? This can be patched manually for our workflow
 by grabbing previous 3.9 version launcher exes and dropping those into the
 python lib venv directory, since then the created venvs use the launchers,
 and correctly resolve the source exes. Version mismatch between the
 launcher and source seems to be an actually
 [https://github.com/python/cpython/pull/11029 valid use case] (for not
 needing venv recreation after the Python itself is updated).
-- 
Ticket URL: <https://trac.osgeo.org/osgeo4w/ticket/814>
OSGeo4W <http://trac.osgeo.org/osgeo4w>
OSGeo4W is the Windows installer and package environment for the OSGeo stack.