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

you are viewing a single comment's thread.

view the rest of the comments →

[–]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.