Greetings,
We are using afanasy as our render farm manager but not much else from the cgru toolset.
I have noticed that the environment running on the farm has prepended to the PATH and PYTHONPATH environment variables, specifically the following prefixes.
PATH PREFIX:
{CGRU_LOCATION}/python;{CGRU_LOCATION}/afanasy/bin;{CGRU_LOCATION}/software_setup/bin;{CGRU_LOCATION}/bin;{CGRU_LOCATION}/dll
PYTHONPATH PREFIX:
{CGRU_LOCATION}/afanasy/python;{CGRU_LOCATION}/lib/python
where {CGRU_LOCATION} is the install location of CGRU.
I've run into some import conflicts caused by the PYTHONPATH change and with running commands like `python script.py` caused by the difference in python version being picked up on the farm vs when the command is run locally.
Ideally I'd like the same runtime environment whether I run the command locally or through afanasy.
Is there some configuration that I am missing for setting the environment that runs on the farm?
Afanasy render environment
Re: Afanasy render environment
Hi!
On Linux CGRU uses system default Python.
On Windows is comes with an own Python located in {CGRU_LOCATION}/python.
And on Linux and on Windows, Python version that is used by CGRU can differ that you software tasks can require.
So your task command should setup need Python first.
For this you can create a command wrapper.
Windows example render.cmd wrapper script:
Most common (famous) CG programs (like Blender, Houdini, Maya, Nuke, ...)
uses own python and do such setup automatically.
On Linux CGRU uses system default Python.
On Windows is comes with an own Python located in {CGRU_LOCATION}/python.
And on Linux and on Windows, Python version that is used by CGRU can differ that you software tasks can require.
So your task command should setup need Python first.
For this you can create a command wrapper.
Windows example render.cmd wrapper script:
Code: Select all
set "MY_PYTHON=c:\my_python"
set "PATH=%MY_PYTHON%;%PATH%"
set "PYTHONHOME=%MY_PYTHON%"
c:\programs\my_soft\render.exe %*
uses own python and do such setup automatically.
Timur Hairulin
CGRU 3.3.1, Ubuntu 20.04, 22.04, MS Windows 10 (clients only).
CGRU 3.3.1, Ubuntu 20.04, 22.04, MS Windows 10 (clients only).
Re: Afanasy render environment
btw,
Recently I started to collect studios that uses Afanasy:
https://cgru.info/#studios
You are welcome!
Recently I started to collect studios that uses Afanasy:
https://cgru.info/#studios
You are welcome!
Timur Hairulin
CGRU 3.3.1, Ubuntu 20.04, 22.04, MS Windows 10 (clients only).
CGRU 3.3.1, Ubuntu 20.04, 22.04, MS Windows 10 (clients only).
Re: Afanasy render environment
Thank you Timur for the quick reply.
I think I understand what you are saying, any wrapper I make should modify the environment so it can run inside or outside the afanasy environment.
In my case, where I want to run `python script.py` should I could make a python.cmd wrapper script?
For the time being would it be possible for me to have the afanasy environment not include the cgru python in PATH and cgru updates to PYTHONPATH?
Otherwise the wrapper way is good. It will just take me a bit more time
I think I understand what you are saying, any wrapper I make should modify the environment so it can run inside or outside the afanasy environment.
In my case, where I want to run `python script.py` should I could make a python.cmd wrapper script?
For the time being would it be possible for me to have the afanasy environment not include the cgru python in PATH and cgru updates to PYTHONPATH?
Otherwise the wrapper way is good. It will just take me a bit more time
Re: Afanasy render environment
It is not possible, as various CGRU (Afanasy) Python tools (scripts, modules) need them to work with a system default (linux) or cgru (windows) Python.
And it is not a bad idea for user scripts, first to setup Python, then use.
As there can be several Python versions installed.
Script should "know" what Python to use.
Timur Hairulin
CGRU 3.3.1, Ubuntu 20.04, 22.04, MS Windows 10 (clients only).
CGRU 3.3.1, Ubuntu 20.04, 22.04, MS Windows 10 (clients only).
Re: Afanasy render environment
Thank you for the answer
I agree, there is nothing wrong with a wrapper that sets up the environment for the script before running.
I agree, there is nothing wrong with a wrapper that sets up the environment for the script before running.