[Bf-committers] Environment Variables for scripts and plugins

[Stefan Andersson]

Hello Everyone
You can all blame Campbell for this mail, I sent a similar one to him
and he thought I should post it here :) He also mentioned that there
was some sort of patch for this once.

___ Environment Variables ___
I would like to talk about Environment Variables in  Blender. I've
been lurking and reading the list for a while, but when the thread
"Setting a default system scripts directory" came up I felt I had to
speak up. One of the things that I do is constructing pipelines, and
also making tools (in python) for these things. And I've always wanted
to fit blender into the pipe, but it hasn't been possible and a few
things are missing (from a pipeline p.o.v).

I'll try and keep it brief and see what others think.

___ Problems ___
1.) You need to have a way to redirect or modify where the scripts are located
2.) Scenes can't find plugins or scripts(tools) that has been written
for a project
3.) Lead TD can't find the rigs or models you have done (don't show up
in the project)
4.) You wrote a nice tool that you would like others at the studio to
use right away
5.) You work in a cross platform environment

___ Solutions ___
Using a few (it has to be few) environment variables will solve about
80% of the problems. The first is to define where the local user
should have their preferences. And the big "3" (Maya, XSI, Houdini)
has a similar solution to this.

$HOME/ (application) / (version) / ( preferences files )

This is the base home for the user preferences and also for scripts
and plugins. This will suite most single users. The structure could be
$HOME/blender/2.5/scripts
$HOME/blender/2.5/plugins
$HOME/blender/2.5/prefs
$HOME/blender/2.5/icons
$HOME/blender/2.5/default_project

We still haven't dealt with any environment variables though. But if
we have these building blocks first, we can also give them environment
variables ( which is required for larger studios ). Blender could have
an internal set of variables that always will be present

BLENDER_SCRIPTS = $HOME/blender/2.5/scripts
BLENDER_PLUGINS = $HOME/blender/2.5/plugins
BLENDER_ICONS = $HOME/blender/2.5/icons
BLENDER_PROJECT = $HOME/blender/2.5/default_project

Once we have set these we can also add more paths if needed. If you
use (as we do at our studio) and application launcher, the script
could easily add more paths to an existing environment. As an example
(using 'durian' as a project name here)

BLENDER_SCRIPTS = $HOME/blender/2.5/scripts:/bsdone/durian/lib/scripts
BLENDER_PLUGINS = $HOME/blender/2.5/plugins:/bsdone/durian/lib/plugins
BLENDER_ICONS = $HOME/blender/2.5/icons:/bsdone/durian/lib/icons
BLENDER_PROJECT =
$HOME/blender/2.5/default_project:/bsdone/durian/000_dev/000_010_mountainShaders/3d

The big benefit of this is that you can now define the hole
infrastructure with variables that you can change when ever you want.
New paths can be dynamicly added or removed. It can be as simple as a
ascii file under $HOME/blender/2.5 that holds those paths that I've
written above, or you can just append them in a python script when you
start the program.

This way you can 'layer' your tools/scripts

Local -> The User
Global -> The Studio tools
Project -> The Current Project you are working on

Since you do create tools for projects, you also want to make sure
that you backup the tools that were used. So in our case the project
specific tools are located under:
[project] /lib/ [application] /scripts

___ Why a "BLENDER_PROJECT" env? __
It's imporant that the application can be aware of which 'shot' it's
working on. If the variable for the project is:
"/bdsone/durian/000_dev/000_010_shaders/3d"
It will look under the '3d' folder for 'scenes' 'textures' 'models'
etc. So you can have relative paths in your scene. This way you can
move the hole '3d' folder and the project will still be valid.
If you use a application launcher, when the project environment is set
the user will always come to the right place at once when they try and
open a file. If they press CTRL-O the will be redirected to
'3d/scenes' directly.
This is something that saves a lot of time when you have a bigger
studio and lots or projects going on. Trying to find scenes is a time
killer.

The Blender file format could be a bit of a problem for this one, but
I think that one has a lot of good things in it and I think these
things could work in conjunction with each other. But at the same time
(as a TD) I don't like at all when things are baked into one big file.

I can speak for hours about this, but this is quite a lot of text and
I think we can take it from here. What do you guys think? Should I
expand it more about how the folder structure for a big pipeline is?


-- 
[ protector of penguins - abuser of pixels ]