5 ms·

> 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

> 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?

Falell 4y ago
Relocating them will actually break things in many cases, especially when native code is involved.
noisenotsignal 4y ago
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.
acomjean 4y ago
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.
jszymborski 4y ago
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.
Helmut10001 4y ago
I have my whole conda env folder symlinked to my second drive. Impossible to store 120GB of environments otherwise.
Izkata 4y ago
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.
senko 4y ago
> 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 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 :-)
korijn 4y ago
Depends if any of your packages use absolute paths (generated at install time for example).
JamesonNetworks 4y ago
I’ve had problems with symlinked python bins not existing in the same place requiring relinking as one example of a problem

Falell 4y ago

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

noisenotsignal 4y ago

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.

acomjean 4y ago

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.

jszymborski 4y ago

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.

Helmut10001 4y ago

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

Izkata 4y ago

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.

senko 4y ago

> 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 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 :-)

korijn 4y ago

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

JamesonNetworks 4y ago

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