[Bf-committers] Setting a default system scripts directory

[Campbell Barton]

No reply but I thought over this a little more and have a proposal for
blender to better fit in with linux package management.
This closely matches The Gimp, which allows system python scripts and
user ones to coexist.

Proposal in point form :)
* ~/.blender stays working, existing configurations wont need to change.
* An optional new DIR is defined for UNIX systems (not win/mac), for
brevity will call it SYS-PATH
* This dir could be named as follows $PREFIX/share/blender-$VERSION --
Eg.  /usr/local/share/blender-2.5
* When the SYS-PATH directory is found it will be used as the primary
directory for scripts, language files, icons etc. (Otherwise
~/.blender will be used like it is now)
* Scrips scan SYS-PATH first (if exists) then ~/.blender, other data
files only use one path (SYS-PATH and fall-back to ~/.blender)
...In most cases using data from both dirs at once is not needed, (you
could conceivably want to access icon themes from ~/.blender &
SYS-PATH, but don't think its so important)
However, scripts are an exception, On a typical linux package you'd
have blender install all data files into /usr/share/blender-2.5 and
then when users want to add their own scripts they can copy into
/home/user/.blender/scripts.


Outcome...
* improves out-of-box experience for users by not treating built-in
files (eg, most of blender2.5s interface) as user settings/data.
* Less trouble to package blender (no scripts copying data to
~/.blender on startup).
* Keep support for existing "local" installs where blender can run
without being installed.
* Packages will install all blender data in /usr/share/blender-2.5.x,
casual users will not create a ~/.blender, however ~/.B.blend will
still be saved into their home dir.
* Existing users who build and run blender dont need to change their
configuration.
* Package managers upgrading blender will remove system scripts and
replace with new ones, ~/.blender (if exists) is untouched.

Details...
* Use a compile time option, like ./configure --prefix="/usr/local"
* $BLENDERPATH used like $PYTHONPATH, allow for non hard-coded
SYS-PATH (Better for re-distribution where users dont install into
/usr/share/.... etc. and don't copy scripts into ~/.blender). Typical
usage this would not need setting.
* Can implement this as opt-in to initially, later can review making it default.
* Will add an "install" target for cmake and scons.

- Campbell

On Sat, Sep 12, 2009 at 10:54 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> Hi, this is an old problem for linux/unix packages and Id like to
> solve this too... some things to think about.
>
> Should this be limited to scripts? - Might it be better to have the
> whole ~/.blender path scanned elsewhere (would include icons, language
> files, .bfont.ttf), otherwise packages still have to have some way to
> have blender find language files in a place other then the home
> folder.
>
> I'd propose one of 4 solutions, some of which have been suggested
> above, and on other occasions.
> 1) Do nothing
> - People packaging blender can have the ".blender" directory installed
> in some directory such as "/usr/share/blender", and use a shell
> wrapper script that copies these files into the home directory on
> startup if it doesn't exist.
> - One of the problems with this is when blender is upgraded, the users
> home holder wont be, unless the startup shell script detects versions.
> - If this becomes the recommended method we must have some way to
> support updates. maybe copy to ~/.blender-2.5 (gimp has versions like
> this)
>
> 2) System wide data files (as well as ~/.blender)
> - This boils down to having blender look in a fixed path for data
> files (including scripts)
> - This directory will be used if ~/.blender is not found (which is the
> case mostly for freshly installed packages), works much nicer for
> updating packages too since users wont have stale copies.
> - At compile time set a prefix (like /usr/share/blender/2_49b),
> similar to --prefix="/usr", often use with ./configure; make; make
> install autoconf setups.
> - PROBLEM, both /usr/share/blender AND /home/User/.blender cant both
> be used at the same time (wont go into details but think this is a
> recipe for disaster).
>
> 3) Environment variable or argument eg. $BLENDER_DATA
> have an environment variable (or command line argument) $BLENDER_DATA
> thats overrides $HOME (when set).
> - This allows for most flexibility, package startup scripts can point
> to whatever location they like, check its there, etc.
> - It would need to save .B.blend and .Blog in $HOME and look for data
> files in $BLENDER_DATA
> - Still doesn't solve system + user scripts.
>
> 4) Only solve for scripts
> Have an env var / argument that scans another path for scripts when
> set. I dont like this much because it only solves one problem but if
> we did this, the scripts could at least co-exist by scanning both the
> system and user scripts.
>
> -----
>
> Personally Id go for 2 or 3, If we go for 3 (an env variable), Id like
> to include a startup shell script that makes use of this in a way we'd
> recommend packagers follow so they don't all go and do their own
> thing.
>
> This isn't especially hard, if we agree on one I can look into adding
> it for 2.49c or 2.5x
>
> On Sat, Sep 12, 2009 at 8:35 PM,  <michael at obberon.com> wrote:
>> On Saturday 12 September 2009 20:10:09 Roger Wickes wrote:
>>> curious - which one of those is your user setting in the folder user
>>>  preferences tab? Secondly, that list does not seem to include the
>>>  bpymodules folder??
>>
>> I did not change the user setting, so I believe that it is the default,
>> ~/.blender. The reason the list turned out the way it did was because on my
>> system, ~/.blender did not exist, so it fell back to /usr/bin/.blender, and
>> then finally /usr/bin/release/scripts (in case the user ran the executable
>> from the source directory). With the directory created, blender does check
>> the ~/.blender/scripts directory, along with
>> ~/.blender/scripts/bpymodules, but does not bother checking anything in
>> /usr/bin.
>>
>> However, this is not the point I was trying to make. There still should be
>> a way to specify a system directory that should also be checked.
>> --
>> Michael Forney <michael at obberon.com>
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> - Campbell
>



-- 
- Campbell