virtualenv alternative

[molinel...@gmail.com]

Hi all,

I typically use virtualenvironments for most of my python development, however I see that people often run into problems using virtual environments for maya python. I also see that people use sitecustomize.py (part of the site package) as an alternative to virtualenv, but I'm not sure i quite understand how it serves as an alternative.

My ultimate goal is keep 3rd party dependencies separate for each maya-python project. How can I accomplish this with sitecustomize.py?

Does anybody have any experience with using virtualenv with maya-python?

[pipoun]

virtualenv has a very different usage than sitecustomize.
Basically, virtualenv can be used as a sandbox for installing python packages, whereas sitecustomize.py is just a python script imported by the python interpreter upon startup ( https://docs.python.org/2/library/site.html ).

One possible workflow:
- startup a new virtualenv, using mayapy as the python interpreter
(- patch the virtualenv activate script file to load the corresponding libpython* dynamic library files (mayapy has some harcoded path coming from autodesk build))
(-install python devel headers to be able to compile python binary modules)
- "pip install" the 3rd party packages you need

- create a sitecustomize.py containing a call to site.addsitedir('/path/to/mayapy_virtualenv/.../site-packages')
- put this file in the maya site-packages installation dir or change the PYTHONPATH environment variable before launching maya.bin/mayapy/mayabatch

If you set directly PYTHONPATH to '/path/to/mayapy/virtualenv/site-packages', it won't be processed correctly (.pth file won't be loaded)

I hope this helps, I don't quite understand what you mean by "maya-python" so perhaps I'm missing something.

[Jesse Kretschmer]

sitecustomize

There can be only one sitecustomize.py in your environment. Python will search the PYTHONPATH and run the first sitecustomize.py found. It does this each time the interpreter is booted up. 

I like to reserve sitecustomize for very basic path python library setup. Mostly, I inject the core studio libraries into the sys.path so I have access from every app/tool. I even have some binary libraries that I want available in every interpreter. This requires some IT/Systems coordination, but it's simple enough once you set all machines to have:

PYTHONPATH=/studio_server/lib/python

My sitecustomize.py inspects the interpreter to determine the correct paths to add to sys.path:

<...>/<pyversion>/<os>/<architecture>

The libraries are some place like this:

/studio_server/lib/python/2.7/Darwin/64bit/opencv

virtualenv

Virtualenv does some trickery with the sys.exec_prefix when launching python from within a virtualenv environment. I believe this is done by using a wrapper binary for the real python binary. This may work for mayapy if you specify the python binary when creating the env:

virtualenv -p <path/to/mayapy> <path/to/new/virtualenv/>

or even:

virtualenv -p <path/to/maya> <path/to/new/virtualenv/>

Alternatives:

sys.path

You can try to directly manipulate the sys.path before you import any necessary libraries. You can even try to use your virtualenv libraries:

import sys
sys.path.append("/path/to/myvirtualenv/lib/python2.7/site-packages")

PYTHONPATH

The PYTHONPATH environment variable can be used on its own if you don't want to play with sitecustomize. It's just a search path and not really that magic. Virtualenv is mostly there to help with the install process, and avoid letting you poison your main library folder.

userSetup.py

userSetup.py is much like sitecustomize except that you can have multiple userSetup.py files and all will be executed when maya starts. It leverages your PYTHONPATH variable. For example, just set do this:

export PYTHONPATH=/studio_server/lib/python:/studio_server/projects/acme123
maya

... Actually, Autodesk has a good writeup on this stuff already:
http://help.autodesk.com/view/MAYAUL/2015/ENU/?guid=Python_Python_in_Maya

There are too many ways to customize maya and the available python packages. You just need to pick your poison.

-j

[Marcus Ottosson]

Great writeup, Jesse.

My ultimate goal is keep 3rd party dependencies separate for each maya-python project.

Are you sure virtualenv is what you want for this? The most common approach I’ve come across is by modifying the environment variables upon application startup. In the case of Maya, on Windows, it could be as simple as:

set MAYA_SHELF_PATH=%MAYA_SHELF_PATH%;\\myserver\pipeline\Maya\Shelves
set MAYA_PLUG_IN_PATH=%MAYA_PLUG_IN_PATH%;\\myserver\pipeline\Maya2015
set PYTHONPATH=%PYTHONPATH%;\\myserver\pipeline\tools;\\myserver\pipeline\System
set MAYA_SCRIPT_PATH=%MAYA_SCRIPT_PATH%;\\myserver\pipeline\Maya\Scripts
"C:/Program Files/Autodesk/Maya2015/bin/maya.exe" %*

You’d then run this, instead of maya.exe directly, and thus inject it with these environment variables. You can then customise which projects are exposed to which libraries and plug-ins by simply having a script like this for each project.

project1_maya.bat
project2_maya.bat
project2_softimage.bat
...

​