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

[Ken Hughes]

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