[Bf-committers] Environment Variables for scripts and plugins

[Charles Wardlaw]

Nice that this is coming on the tails of the last conversation.
Basically, I love it.  It sounds well thought out and solves all my current
qualms with how Blender manages its files on OS X and Windows. +1.  I think
local files (in $HOME) should be used first, then global (from ENV variable
search paths).

I like project structures, but at the same time I don't want Blender
randomly creating extra folders and files wherever I save .blends like Maya
does.  As long as it's well-behaved and can work without a project structure
(as it does currently) I'm all for that, too.
~ C



On Thu, Sep 24, 2009 at 4:19 PM, Stefan Andersson <
stefan.andersson at bohmation.org> wrote:

> 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 ]
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>