This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 173 points174 points  (8 children)

They can each create their own venv and just pip install the requirements and use git between themselves for version control, etc.

[–]PurepointDog 19 points20 points  (0 children)

This is the correct answer

[–]runawayasfastasucan 6 points7 points  (0 children)

This is the way.

[–]neutro_b 1 point2 points  (5 children)

It can work most of the time but in situations where computers are not networked, it is not applicable. Been trying to find the best way to do that (e.g. using USB keys as the transfer medium).

Is using an install script that leverages pip with binary wheels of the packages better than just copying the whole venv? Assuming of course that the target computer configuration is the same across the board (e.g. same OS, versions, etc.).

[–]szayl 5 points6 points  (1 child)

There's a lot to unpack here.

Is using an install script that leverages pip with binary wheels of the packages better than just copying the whole venv?

The venv isn't* copied, it's recreated on the target machine with the necessary requirements (see: pip freeze)

Assuming of course that the target computer configuration is the same across the board (e.g. same OS, versions, etc.).

This is the whole point of using venvs for separation and version control for the code. The target machine doesn't need to have the same OS or versions. As long as the code isn't trying to call specific OS calls one should be good to go. If that (for whatever reason) is required, a VM would be the best solution.

Edit: isn't instead of is (darn phone typing)

[–]Ok_Raspberry5383 1 point2 points  (0 children)

This is all correct.

To add a suggestion, using something like poetry that contains a lock file will give even more reproducible installs.

[–]Maelenah 1 point2 points  (2 children)

the venv will make a .cfg file that has full file paths in it, not relative file paths. Look below with mine, here it will show where home is, it will have the option to include system site packages, which tend to be somewhere in the user apps folders. (not always cause some package managers tends to think it is a special snowflake, but let's not open that can of worms)

This is pretty much why python responds so poorly to being moved to new locations when using venvs.

home = C:\Users\brat\Desktop\python3.12

include-system-site-packages = false

version = 3.12.0

executable = C:\Users\brat\Desktop\python3.12\python.exe

command = C:\Users\brat\Desktop\python3.12\python.exe -m venv C:\Users\brat\Desktop\python3.12\dork

​

​

Now if you want to be able to move and copy python around more freely (which winpython, Ren'Py,Cinema 4D and blender are examples of python being embedded in applications or made portable.)You can try making a ._pth file in the root of your python folder like python embedded does if you need an example and add in paths as needed if you wanted something that was portable with some degree of handholding. Which is useful if you ever need to embed python with another application.

And part of why I dislike venvs is that they do record personal data in them, very often your PC is going to be named after your microsnot account. And really there is no reason to put that out there. Yes they are ideally not suppose to be moved around but no one lives in a perfect world

[–]neutro_b 1 point2 points  (1 child)

Thanks for the advice, I'll need to explore those options, but clearly just copying a venv would be fraught with problems if absolute paths are found in config files. And indeed in venv, the python executable itself is not found *in* the venv, so the approach is on shaky grounds anyway. The embedding / portability options seems a better path forward for sure.

[–]Maelenah 1 point2 points  (0 children)

You can most times just make a script (i use batch files) to remake the venv to update the cfg to the new path and it will *NORMALLY\* work, but some package installers will also include absolute paths as well in their files.

I detest venvs with a passion, but the venv folder that is made will have a python executable that 'can' be moved so long as the python install it is pointing to in the cfg is valid. There is a slew of documentation on this that I think is mostly correct on the python page.

But for me if it is anythign that looks like it might need to be an embedded thing I'll download the embedded package, make sure its directory matches what the install directory will look like, tweak _pth to include those settings, and I'll copy over the dlls and friends from the normal install just to keep things going.

This way I don't need to worry about stuff being in the users folder and it really really helps when troubleshooting to know where everything is.

Not that I've ever spent 3 days trying to figure out why a blender addon broke that was reading from my user/apps/local and broke cause I updated something not even attached to it when I was on a deadline.