[Bf-python] Adding a new way to deal with libraries

[Campbell Barton]

Ken Hughes wrote:
> Had time to think some about this, so want to continue the discussion to 
> see if I'm on the right track.
> 
> Martin Poirier wrote:
>> --- Campbell Barton <cbarton at metavr.com> wrote:
>>
>>> it may be that we have deal with 2 sets of lib data
>>> - data thats currently in blender (as accessed by the outliner) -
>>> and data that use scripter has loaded, but is yet to be used by
>>> blender. I think thats ok. if its not used then it wont be there next 
>>> time
>>> blender is loaded.
>>
>> Having virtual data separated from the Blender data
>> that is loaded from the library on a special call is a
>> big No No for me.
>>
>> While lazy linking/appending would be good for batch
>> process (by that I mean: load library, specify the
>> data to be linked/appended, link/append all data at
>> once), I think the default mode should definitely be
>> atomic load/link/close operations, even if that would
>> be a bit slower.
>>
>>> each lib from libraries can be its own pyType thats
>>> only stores a filename, and has attributes for accessing data
>>> withing the blend file.
>>>
>>> for ob in lib.objects: could be an list/iterator of
>>> strings.
>>>
>>> ob = lib.object.link(obname)
>>>
>>> could load the object into blender and return the
>>> python object.
>>
>> Also, alternatively, the user could specify a list of
>> names to link them all at once.
>>
>> There's the question of where those objects are linked
>> though. AFAIK, Blender doesn't naturally (that is,
>> with user interaction) have zero-user objects, though
>> I'm not sure the internals would really freak out if
>> that happened. If possible, the objects should be
>> unlinked to a scene, if not, current scene is probably
>> a sensible solution. All other data should be unlinked
>> (if link/appended directly).
> 
> Seems to me we want something which will link/append data to the .blend 
> file but not link/append objects; i.e.,
>    mat = lib.materials.append('Material') # copy material from lib
> but not
>    ob = lib.objects.append('Cube') # copy object from lib
> We're trying to get away from creating objects outside of the context of 
> some scene, so lib.objects.*() shouldn't return a Bpy_Object itself.
> 
> What I'm thinking for objects is that lib.objects.*() returns a BPy 
> object of some kind which has enough information to append/link the 
> objects using scene.objects.new(), but without actually creating any 
> Blender data.  scene.object.new() would check for this new BPy type, 
> then call the appropriate routines to create the new Blender object.
> 
>>> so say you want a group called 'mygroup'
>>>
>>> lib = bpy.libraries.load('//someblend.blend')
>>> group = lib.groups.link('mygroup')
>>>
>>
>> lib is an external data source with different data
>> subtypes that each allow linking/appending whereas
>> bpy.groups (and the like) represents internal data
>> source (that allow manipulation of those data
>> elements). Linking/appending from an external source
>> adds the data into the internal source which can then
>> be manipulated.
> 
> bpy.libraries seems unnatural to me; is it a sequence of libraries the 
> user has already accessed?  If so, I assume we would implement an 
> interator for it also, but can you also access an item using the 
> operator []?  Other than being a "history" of libraries I can't see an 
> advantage for it.  You can't assume all the libraries are still 
> available (the user could delete one) so internally you still have to 
> repeat the same work to check for existence, etc.  Otherwise, we might 
> as well just create a bpy.loadLibrary() method that returns the object 
> and forget about the interator.
> 
> Ken


Hi Ken, heres some plans I had for bpy.libraries

in regards to bpy.libraries


typedef struct {
	PyObject_VAR_HEAD /* required python macro */
	char filename[FILE_MAXDIR + FILE_MAXFILE]
} BPy_Lib;


a library wouldnt be linked to anything, just a filename...

so "for lib in bpy.libraries" - would only return a list or iterator of 
of open libraries, as you point out, its not THAT usefull...


When dealing with libs, the Python API would have to deal with loading 
and unloading the blend files, this would be done whenever the lib-data 
was accessed. so the user removing a file is ok. just return an error 
next time its accessed.

a BPy_Lib isnt realy linked into bpy.libraries, so new bpy.libraries 
could be created..

lib = bpy.libraries.load('//mylib.blend')

then the scripter could load some data from the lib, and it would then 
become a part of bpy.libraries

lib filenames should also be writable..

lib.filename = '//....' - this would inspect blender for a name mathcing 
  "lib" and rename its filename to the assigned one..