Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

python setup.py clean destroys venv #1203

Open
levicki opened this issue Jan 26, 2025 · 2 comments
Open

python setup.py clean destroys venv #1203

levicki opened this issue Jan 26, 2025 · 2 comments

Comments

@levicki
Copy link

levicki commented Jan 26, 2025

🐛 Bug

Clean action in the setup.py uses .gitignore as a source of what to remove from the folder tree.

Given that venv/ is listed in it, it gets destroyed.

Command

python.exe setup.py clean

To Reproduce

Steps to reproduce the behavior:

  1. Clone repo
  2. cd into xformers
  3. Create venv
  4. install requirements
  5. run python setup.py clean

Subsequent attempts to run python setup.py result in pyvenv.cfg missing error because venv gets (partially) deleted.

Expected behavior

One would expect that build process only cleans files that it created itself, not unrelated content.

The file is called .gitignore for a reason — it's supposed to be used to tell git what to ignore, not to tell setup.py what can be safely deleted.

Environment

PyTorch version: 2.5.1+cu124
Is debug build: False
CUDA used to build PyTorch: 12.4
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 11 Enterprise
GCC version: (MinGW-W64 x86_64-ucrt-posix-seh, built by Brecht Sanders, r8) 13.2.0
Clang version: Could not collect
CMake version: version 3.31.4
Libc version: N/A

Python version: 3.11.9 (tags/v3.11.9:de54cf5, Apr 2 2024, 10:12:12) [MSC v.1938 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.22631-SP0
Is CUDA available: True
CUDA runtime version: 12.8.61
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 4090
Nvidia driver version: 566.36
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Additional context

N/A

@lw
Copy link
Contributor

lw commented Jan 27, 2025

Uhm, I'm not sure what exactly to think of this. Overall I do agree with the current behavior: clean should bring the repository back to its "original" state, as if it were just checked out from GitHub, thus the venvs should be removed.

Do you know if it's a best practice to store the venv inside the repo? For conda environments, for example, they live in an entirely unrelated directory.

@levicki
Copy link
Author

levicki commented Jan 27, 2025

Uhm, I'm not sure what exactly to think of this. Overall I do agree with the current behavior: clean should bring the repository back to its "original" state, as if it were just checked out from GitHub, thus the venvs should be removed.

I am not sure why the venv/ should be removed by clean at all though? Could you elaborate on that?

I don't see how it affects the build process other than forcing you to reinstall 3+ GB of packages. Even if you have them in your pip cache and don't have to download them again it is still a waste of SSD writes not to mention time to delete them and have to install them again.

Do you know if it's a best practice to store the venv inside the repo? For conda environments, for example, they live in an entirely unrelated directory.

I am not saying it is, and perhaps a temporary workaround for me could be to not name my venv folder any of:

env/
venv/
ENV/
env.bak/
venv.bak/

Since those are explicitly listed in .gitignore. However, if that list changes in the future to include whatever name I used for my venv then what? It also will show said folder as a git change for me since it is not in .gitignore making it harder to track other changes.

Also, sometimes you can't store the venv outside of a repo (think CI/CO build where you can't write outside repo folder).

So what I am complaining about is the abuse of .gitignore to mean something it isn't supposed to mean.

A list of files and folders which should be ignored by source control should not be treated as a list of files and folders which can be deleted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants