Hacker News Reader

Comment by warner25 | Hacker News Reader

> One point I would like to make is how virtual environments are designed to be disposable and not relocatable.

Is the author saying that relocating them will actually break things, or that it's just as easy to recreate them in a different location? Because I've moved my venv directories and everything still seemed to work OK. Did I just get lucky?

View on HN

It's a gamble to move venvs.

The real way to move venvs is to freeze the venv (i.e. make a requirements.txt) and then pip -r requirements.txt to recreate the venv.

This process is really the only thing about venvs that ever causes me trouble.

Depends if any of your packages use absolute paths (generated at install time for example).

There’s also relocating across machines. For example, maybe your build environment has access to internal registries but your release environment does not. I naively thought you could build your venv and just copy to the new machine (both environments were Ubuntu) but ran into errors (due to links breaking). We also used pex for a bit, which is kind of like building a binary of a venv, and that eventually stopped working too when the C ABI was no longer the same between environments. There didn’t seem to be an easy way to pick the ABI version to target when creating the pex file, so I gave up and just downloaded the wheels for internal packages in the build.

By default when you activate a virtualenv, it uses hardcoded absolute paths (determined at the time the environ was created), so moving the directory will break it.

> relocating them will actually break things

Yes, absolute paths are hardcoded in several places.

I actually have a use case for copying/relocating them (for https://apibakery.com), and simple search/replace of paths across the entire venv works, but I wouldn't recommend that as a best practice approach :-)

I’ve had problems with symlinked python bins not existing in the same place requiring relinking as one example of a problem

I’ve tried to move things and broken everything. (Conda environments). I tried replacing the paths in the files and it didn’t work. We run a bunch of different tools with various python requirements and would like to be able to duplicate them for the next tool.

We ended up making a new environments for each. Honestly it’s a bit of a mess.

Relocating them will actually break things in many cases, especially when native code is involved.

I have my whole conda env folder symlinked to my second drive. Impossible to store 120GB of environments otherwise.

Reply on news.ycombinator.com