Cryptic error when failing to upgrade `pdm` in a `tox`-managed venv

[ncoghlan]

I just ran into a problem where pdm, tox, and tox-pdm unexpectedly stopped playing nice on a Windows machine:

S:\path\to\project> tox -e py3.12
py3.12: install_deps> pdm sync --no-self --group dev
Synchronizing working set with resolved packages: 0 to add, 1 to update, 0 to remove

  x Update pdm 2.17.3 -> 2.18.1 failed
  x Update pdm 2.17.3 -> 2.18.1 failed

... snip traceback details ...

PermissionError: [WinError 32] The process cannot access the file because it is being used by another process:
'S:\\path\\to\\project\\.tox\\py3.12\\Scripts\\pdm.exe'

  x Some package operations failed. 1/1 0:00:00
INFO: Inside an active virtualenv S:\path\to\project\.tox\py3.12, reusing it.
Set env var PDM_IGNORE_ACTIVE_VENV to ignore it.
STATUS: Resolving packages from lockfile...
See C:\Users\Alyssa\AppData\Local\pdm\pdm\Logs\pdm-install-4rac_qnn.log for detailed debug log.
[InstallationError]: Some package operations failed.
WARNING: Add '-v' to see the detailed traceback

The PDM lock file had been updated elsewhere and then pulled over to this Windows machine. The fix was to destroy and recreate the tox environment rather than trying to updated it in place:

S:\path\to\project> tox -re py3.12
... output for test run working as expected ...

This isn't the same as the nox VIRTUAL_ENV handling issue reported in pdm-project/pdm#2297, but I did end up there while trying to make sense of the failure.

Perhaps tox-pdm could detect when the venv itself contains pdm and it is attempting to upgrade it on Windows?

(alternatively, there may be a genuine bug here, and tox-pdm should be running [sys.executable, "-m", "pdm"] rather than running pdm directly?)