Dev:2.5/Source/Installation/Proposal

Installation

This proposal unifies the ideas in several proposed changes to Blender's method of storing and retrieving external data. Much of this follows directly from the 'environment variables' proposal, which I agree with, with some minor adjustments.

In summary:

• We split

• System Files: Default blender data such as ui scripts
• User Files: Saved configurations, user-owned data such as edited or added scripts

These are stored in separate locations.

• We store both System and User files split by Blender version number within their parent folders.

• System and User files are kept in OS-specific locations using OS APIs, able to be overridden by environment variables.

• Individual config/data files are renamed to be less cryptic

• For now, we will just worry about fixing up the issue of finding paths, using similar to existing APIs in Blender. We won't wrap FILE etc for now.

System data files

Default data files such as translations, icons, etc. required by Blender are saved in system-wide storage at installation time. These are read-only by Blender.

example: BLENDER_SYSTEM_DATAFILES

unix: /usr/share/blender/2.56/datafiles
osx: blender.app/Contents/MacOS/2.56/datafiles
win: C:\Program Files\Blender\2.56\datafiles

User data files

User-specific data files are installed as needed in user-specific locations

example: BLENDER_USER_DATAFILES

unix: ~/.blender/2.56/datafiles
osx: ~/Library/Application Support/Blender/2.56/datafiles
win: C:\Users\Username\AppData\Blender\2.56\datafiles

Other variants include, BLENDER_SYSTEM_SCRIPTS, BLENDER_SYSTEM_PLUGINS, and BLENDER_USER_* counterparts.

User Configuration Files

Blender should run fully by default without any configuration files needed. User-specific config files are created as needed in user-specific locations.

example: BLENDER_USER_CONFIG:

unix: ~/.blender/2.56/config
osx: ~/Library/Application Support/Blender/2.56/config
win: C:\Users\Username\AppData\Blender\2.56\config

System Configuration Files

As an option that is not defined by default, system configuration files can be used, to provide customised defaults to all users, taking precedence over the built-in blender defaults, but under user configurations. This can be useful for large site installations such as schools to have customised default preferences.

System configuration files are read-only by Blender, all newly saved preferences go to USER_CONFIG. example: BLENDER_SYSTEM_CONFIG

Not defined by default, can be any path, but generally alongside BLENDER_SYSTEM_DATA.

Temporary files

Temporary caches/backups such as 'last session' .blend file, or temporary EXRs are stored in user-specific locations. This should not use system-wide temp locations such as /tmp, to prevent them getting deleted and to prevent other users from affecting them.

example: BLENDER_TEMP

unix: ~/.blender/2.56/temp
osx: ~/Library/Application Support/Blender/2.56/temp
win: C:\Users\Username\AppData\Blender\2.56\temp

File Naming

We can rename the configuration files used by Blender to be less cryptic:

• startup.blend ( .B.blend )
• bookmarks.txt ( .Bfs )
• recent-files.txt ( .Blog )

We can also change the quit.blend to:

• <saved_filename>_<process_id>_quit.blend

to avoid conflicts from multiple blender sessions. Saving the filename as part of the title will also allow users to more quickly identify older sessions to restore.

Temp files can also be changed similarly, to:

• <saved_filename>_<process_id>_temp.blend

to more easily identify stored temp files, and perhaps can be used to automatically restore temp versions when they are older than the saved 'real' version.

Running Locally

A feature that some people find useful is to run blender 'locally', out of a self-contained folder, without needing to install in the system. To support this, when retrieving the BLENDER_SYSTEM_DATAFILES path, blender can first check for a 'datafiles' path in the same folder as the blender executable, and use that first. Same for other associated paths such as BLENDER_SYSTEM_SCRIPTS and BLENDER_SYSTEM_PLUGINS.

These only override the BLENDER_SYSTEM_* entries, BLENDER_USER_* still takes precedence in general situations.

Implementation

1) As a 'stage 1' quickly achievable target, we can possibly ignore the environment variables part, and concentrate on the Blender internal API. This can use the same names, but just retrieving path info from OS-specific functions. eg.

BLI_getfolder(BLENDER_USER_DATAFILES)

2) Add ability to read/overwrite these paths with environment variables

References

http://wiki.blender.org/index.php/Dev:2.5/Source/Installation/ResourceFilePaths http://wiki.blender.org/index.php/Dev:2.5/Source/Installation/EnvironmentVariables http://wiki.blender.org/index.php/Dev:2.5/Source/Installation/Unix_FHS

--Matt Ebb 08:16, 11 May 2010 (UTC)