[Bf-committers] Setting a default system scripts directory
Brecht Van Lommel
brecht at blender.org
Sat Sep 19 12:39:52 CEST 2009
I agree with the proposal basically. The folder ~/.blender should be
the place for the user to configure & add things, while
$PREFIX/share/blender or ./.blender should be used for files that come
One thing I'm not sure about is how to deal with different versions.
My preference is to use /usr/local/share/blender/2.5 over
/usr/local/share/blender-2.5, but that's a detail.
Do we use a version number inside ~/.blender? I may be useful to let
Blender look into ~/.blender/2.5 and then ~/.blender. This way you
could install scripts for particular versions, but not necessarily
worry about it if you don't want to.
Further, I think we should move .B.blend, .Bfs and .Blog into
~/.blender. I think Ton wanted to split up .B.blend into parts also,
it may be better to avoid writing too many files in the home directory
and keep them together in a folder.
On other operating systems we should also do a similar separation
between user config and application, using whatever folder is
appropriate. Not that I expect you to implement it, but may be nice to
write the functions in such a way that other operating systems can
plug in different paths.
On 9/19/09, Campbell Barton <ideasman42 at gmail.com> wrote:
> 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
> * 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
> * Package managers upgrading blender will remove system scripts and
> replace with new ones, ~/.blender (if exists) is untouched.
> * 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
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers