37 ms·

You can certainly just delete a venv. `rf -rf venv` I'm not sure what kind of custom path you need, but you can put a venv anywhere you want that's practical.

You can certainly just delete a venv. `rf -rf venv` I'm not sure what kind of custom path you need, but you can put a venv anywhere you want that's practical. Yes, when you create it, you need leave it there. but they're trivial to create. `python3 -m venv [path to venv]` Installing packages is a LOT faster than npm. There's definitely issues with python's setup as a global interpreter, but these arn't them.

oblio 3y ago
You should be able to copy paste the folder across identical machines. Now it's not recommended for... reasons.
- ehutch79 3y ago
  Why would you do that? I wouldn't do that with node_modules either. If they're 100% cloned VMs or something, I guess? I'd still probably just build wheels and use those.
  - pgwhalen 3y ago
    > Why would you do that? Deployment, sharing for development, etc.
  - oblio 3y ago
    > Why would you do that? I hate this question. It's basically "why are you stupid"? I'm a professional with 20 years of experience with ecosystems ranging from Java, .NET, Ruby, Python, etc., so if I write something, I probably have a valid use case. The opposite question should be asked: why can't I do that? And the answer is, frankly, either lazy/bad design on the Python ecosystem part or backwards compatibility with an existing but bad system. In a well designed system venvs would be by default copy-able to another equivalent system since there's little to lose and a lot to gain, for example, access to the simplest and most reliable deployment system invented in history, the <<copy-paste deployment system>>. The fact that we have entire generations of developers that can't fathom why someone would want that basically says all it needs to say about the degree of over engineering that's now standard.