From 52911249a7fa750967475a2f85fef66c2eb7a23e Mon Sep 17 00:00:00 2001 From: Ashesh Vashi Date: Mon, 7 Sep 2026 17:20:49 +0530 Subject: [PATCH 1/2] fix(pkg): stop the Windows build overwriting the venv's pip CREATE_VIRTUAL_ENV creates a virtualenv and then copies the whole of the system Python's Lib over it, so that the relocated interpreter has a standard library to use. That copy includes Lib\site-packages, and XCOPY /Y overwrites the files that exist on both sides without removing the ones that only exist in the venv, so the venv's freshly seeded pip ends up spliced together with whatever pip C:\Python313 happens to have. That was harmless while the two layouts agreed. pip 26.2 turned pip/_internal/build_env from a module into a package, so on a builder whose system pip predates 26.2 the new build_env/ directory survives the copy whilst utils/misc.py is overwritten by the older one, and every subsequent pip invocation dies before it does anything: File "...\pip\_internal\build_env\installer.py", line 22, in from pip._internal.utils.misc import get_runnable_pip ImportError: cannot import name 'get_runnable_pip' from 'pip._internal.utils.misc' It cannot recover on its own either, since the next line of the script is the pip invocation that upgrades pip. Copy the standard library with ROBOCOPY and exclude site-packages, which the venv is entitled to keep to itself. ROBOCOPY rather than XCOPY because /XD takes a directory to skip and the existing :CHECK_ROBOCOPY_ERROR helper already handles its exit codes; /R:3 /W:5 so a locked file fails the build rather than retrying for a million attempts. --- Make.bat | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Make.bat b/Make.bat index 817d266f5f6..d076d92a5d0 100644 --- a/Make.bat +++ b/Make.bat @@ -164,7 +164,11 @@ REM Main build sequence Ends "%PGADMIN_PYTHON_DIR%\Scripts\virtualenv.exe" venv XCOPY /S /I /E /H /Y "%PGADMIN_PYTHON_DIR%\DLLs" "%TMPDIR%\venv\DLLs" > nul || EXIT /B 1 - XCOPY /S /I /E /H /Y "%PGADMIN_PYTHON_DIR%\Lib" "%TMPDIR%\venv\Lib" > nul || EXIT /B 1 + REM Copy the standard library, but NOT site-packages: the venv already has its + REM own seeded pip there, and overwriting only the files the system Python also + REM has leaves a mix of two pip versions behind. + ROBOCOPY /E /R:3 /W:5 "%PGADMIN_PYTHON_DIR%\Lib" "%TMPDIR%\venv\Lib" /XD "%PGADMIN_PYTHON_DIR%\Lib\site-packages" > nul + CALL :CHECK_ROBOCOPY_ERROR || EXIT /B 1 ECHO Activating virtual environment - %TMPDIR%\venv... CALL "%TMPDIR%\venv\Scripts\activate" || EXIT /B 1 From a002cfbaca52a0434d1b22ddc240a62c59421001 Mon Sep 17 00:00:00 2001 From: Dave Page Date: Mon, 7 Sep 2026 15:00:03 +0100 Subject: [PATCH 2/2] fix(pkg): make the Windows build's ROBOCOPY failures diagnosable Follow-up review fixes to the site-packages exclusion. Exclude site-packages by name rather than by full path. The full path is built from PGADMIN_PYTHON_DIR, so if that is ever set with a trailing backslash the source and the /XD argument both gain a doubled separator; should the match then fail, site-packages is copied over the venv again and the build fails with the same ImportError this was meant to remove. No directory inside the standard library is legitimately called site-packages, so matching by name is both simpler and unconditional. Drop "> nul" from both ROBOCOPY calls in favour of /NFL /NDL /NP. ROBOCOPY writes its errors to stdout, so with the redirect in place a copy that returns 8 or more aborted the build with nothing in the log to say which file or share was at fault; the switches suppress the per-file noise whilst keeping the header, the summary and any errors. Guard the copy of the web directory with "|| EXIT /B 1" as well, since EXIT /B inside :CHECK_ROBOCOPY_ERROR returns from the label rather than from the caller and a failed copy was therefore ignored, leaving the build to package an incomplete tree. Guard virtualenv.exe likewise: with the standard library now copied by ROBOCOPY, which creates its destination, a failure there would otherwise surface later at the activate step instead of where it happened. --- Make.bat | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Make.bat b/Make.bat index d076d92a5d0..c6fbac77446 100644 --- a/Make.bat +++ b/Make.bat @@ -161,13 +161,13 @@ REM Main build sequence Ends CD "%TMPDIR%" REM Note that we must use virtualenv.exe here, as the venv module doesn't allow python.exe to relocate. - "%PGADMIN_PYTHON_DIR%\Scripts\virtualenv.exe" venv + "%PGADMIN_PYTHON_DIR%\Scripts\virtualenv.exe" venv || EXIT /B 1 XCOPY /S /I /E /H /Y "%PGADMIN_PYTHON_DIR%\DLLs" "%TMPDIR%\venv\DLLs" > nul || EXIT /B 1 REM Copy the standard library, but NOT site-packages: the venv already has its REM own seeded pip there, and overwriting only the files the system Python also REM has leaves a mix of two pip versions behind. - ROBOCOPY /E /R:3 /W:5 "%PGADMIN_PYTHON_DIR%\Lib" "%TMPDIR%\venv\Lib" /XD "%PGADMIN_PYTHON_DIR%\Lib\site-packages" > nul + ROBOCOPY /E /R:3 /W:5 /NFL /NDL /NP "%PGADMIN_PYTHON_DIR%\Lib" "%TMPDIR%\venv\Lib" /XD site-packages CALL :CHECK_ROBOCOPY_ERROR || EXIT /B 1 ECHO Activating virtual environment - %TMPDIR%\venv... @@ -220,8 +220,8 @@ REM Main build sequence Ends RD /Q /S "%WD%\web\pgadmin\static\js\generated\.cache" 1> nul 2>&1 ECHO Copying web directory... - ROBOCOPY /S "%WD%\web" "%BUILDROOT%\web" > nul - CALL :CHECK_ROBOCOPY_ERROR + ROBOCOPY /S /NFL /NDL /NP "%WD%\web" "%BUILDROOT%\web" + CALL :CHECK_ROBOCOPY_ERROR || EXIT /B 1 ECHO Installing javascript dependencies... CD "%BUILDROOT%\web"