Pdm deletes existing virtualenv on calling pdm list or similar

[samrensenhouse]

• [x] I have searched the issue tracker and believe that this is not a duplicate.

Make sure you run commands with -v flag before pasting the output.

Steps to reproduce

Hard to give an exact example, but I think this should suffice (the same set of dependencies weren't as slow on other colleagues machines and didn't trigger the issue)

1. Have a project with a lot of dependencies installed such that calling

myproj\.venv\Scripts\python.exe -c "import platform; print(platform.python_version())"

takes more than 5 seconds. 2. Call a pdm command like pdm list or pdm run or pdm install

Actual behavior

1. Timing the above command (using a custom batch script):

timecmd myproj\.venv\Scripts\python.exe -c "import platform; print(platform.python_version())"
3.8.2
command took 0:0:7.47 (7.47s total)

2. Calling pdm list deletes the current virtual env because it is not considered valid

pdm list
python.use_venv is on, creating a virtualenv for this project...
Cleaning existing target directory C:\dev\myproj\.venv
Virtualenv is created successfully at C:\dev\myproj\.venv
┌──────┬─────────┬──────────┐
│ name │ version │ location │
├──────┼─────────┼──────────┤
└──────┴─────────┴──────────┘

Expected behavior

• pdm list or similar does not delete an existing virtualenv

Environment Information

# Paste the output of `pdm info && pdm info --env` below:
python.use_venv is on, creating a virtualenv for this project...
Cleaning existing target directory C:\dev\myproj\.venv          
Virtualenv is created successfully at C:\dev\myproj\.venv       
PDM version:                                                    
  2.4.3                                                         
Python Interpreter:                                             
  C:\dev\myproj\.venv\Scripts\python.exe (3.8)                  
Project Root:                                                   
  C:/dev/myproj
Project Packages:                                               
  None                                                          
{                                                               
  "implementation_name": "cpython",                             
  "implementation_version": "3.8.2",                            
  "os_name": "nt",                                              
  "platform_machine": "AMD64",                                  
  "platform_release": "10",                                     
  "platform_system": "Windows",                                 
  "platform_version": "10.0.22621",                             
  "python_full_version": "3.8.2",                               
  "platform_python_implementation": "CPython",                  
  "python_version": "3.8",                                      
  "sys_platform": "win32"                                       
}                                                               

I am not sure if this is more appropriate to raise in the find-python project, but it appears when pdm checks if a virtualenv is valid, part of that check inside of findpython is getting the python version. If it takes longer than 5 seconds to do so, it is considered invalid and triggers the deletion.

I guess I would not expect a command like pdm list to potentially delete a folder. Separate from that, I think findpython could be updated to check for the python version by calling python with the -S option (https://docs.python.org/3/using/cmdline.html#cmdoption-S) which drastically speeds up the process on my machine with the same virtualenv to 0.14 seconds.

command = [self.executable.as_posix(), "-S" "-c", script]

[samrensenhouse]

I started looking more into this and after setting pdm config install.cache False, python starts up fast again without any other changes needed.

[frostming]

It will be cleared if the existing .venv doesn't match the requires-python setting in pyproject.toml

[samrensenhouse]

From what I can tell, the slow response time makes the python interpreter be considered invalid even before it checks if the version matches.

Additionally, the existing .venv matches the requires-python:

C:\dev\myproj (main -> origin)                                                   
λ .venv\Scripts\python --version                                                                
Python 3.8.2                                                                                    
                                                                                                
C:\dev\myproj (main -> origin)                                                   
λ cat .pdm.toml                                                                                 
[python]                                                                                        
path = "C:\\dev\\myproj\\.venv\\Scripts\\python.exe"                                            
                                                                                                
C:\dev\myproj (main -> origin)                                                   
λ cat pyproject.toml | grep requires-python                                                     
requires-python = ">=3.8"                                                                       
                                                                                                
C:\dev\myproj (main -> origin)                                                   
λ pdm info                                                                                      
python.use_venv is on, creating a virtualenv for this project...                                
Cleaning existing target directory C:\dev\myproj\.venv

[andreas-vester]

I experience the same behaviour. Existing .venv folder will be deleted once I run commands like
pdm run ...

@samrensenhouse Deactivating the cache did the trick on my end, too.