[Bf-python] bpy.libraries modules (was "Adding a new way to deal with libraries")

[Campbell Barton]

Martin Poirier wrote:
> --- Ken Hughes <khughes at pacific.edu> wrote:
> 
>> Ok, here's a epydoc description of the proposed new
>> module for 
>> bpy.libraries:
>>
>> http://www1.pacific.edu/~khughes/Libseq-module.html
>>
>> As Martin suggested, it is atomically
>> load/link/close for each action. 
>> It also will incorporate the equivalent to
>> Library.Update() (or 
>> Library.Load() with update=1).
>>
>> Also, in keeping with the design goal of not
>> allowing the creation of 
>> Blender objects which are not linked to scenes, the
>> types which are 
>> returned by the libraries.objects.link() and
>> .append() methods are 
>> "pseudo-types" which must be passed to
>> scene.objects.new() in order to 
>> actually create the object.
>>
>> Feedback, comments, etc., welcome.
> 
> Excellent, I like what I'm seeing.
> 
> So, if I got this write, the actual data append/link
> only happens when the pseudo-object is linked to an
> already existing scene datablock (object->scene).
> 
> What would be nice would be that that pseudo-object is
> implemented as a materialization proxy (pardon the
> technobable). That is, the pseudo-object provides the
> same methods/properties as a real Object except that
> any call/access throws an error until the object is
> really added to a scene, in which case the calls are
> forwarded to the real object (a reference is kept when
> the scn.objects.new call is made).
> 
> This is extra work though and I'm not sure it'd be
> really worth it.
> 
> Also, that's not mentioned, but I assume the load
> function throws IOError if the lib doesn't exist (and
> possibly ValueError if it's not a blend file).
> 
> Good work.
> 
> Martin


Hi Ken, Martin...

this pretty much follows what I suggested so of course Im pretty happy 
with it ;)

The 2 problems of the old were Objects not in a scene and objects 
without data..
The latter is far more important and Id consider objects having to be in 
a scene as more something we should encourage by the API's design, 
rather then enforce everywhere.

for instance somebody can add an object and remove it, and the object 
wont be in a scene. we cant really help this.

There are a few ways we might get around having psudo objects...

1) allow objects to be imported and not be in a scene.
	I dont realy mind this much, its not ideal but will fit will other data 
types .
2) create the object in the current scene.
	dont like this option at all but its there.
3) take a scene as an argment, similar to what antont was suggesting, 
Im 	not keen on it but seeing were out of options it could be ok.
	 lib.objects.link("MyOb", Scene)
	This could be a special case, Id prefer be explicit with the scene 
rather then adding to the active scene, and its probably worth the 
inconsistancy just to avoid psudoObjects.


Then again psudo objects may not be so bad...as long is they dont do 
anything other then link to a scene. if they start to do some things 
objects to - like have a name even. the difference starts to blur and 
people would get confused.


A problem could be that...
scn.objects.link(psudo_ob)
will add the object, but will the psudo object suddenly act like a 
normal object?

from a scripters standpont Id expect it to but this may be tricky to get 
working properly.

Id choose option 1 or 3 rather then add psudo objects.