[Pythonmac-SIG] weak-link libraries problem

[William Kyngesburye]

On Apr 11, 2006, at 9:24 PM, Bob Ippolito wrote:

>
> On Apr 11, 2006, at 6:46 PM, William Kyngesburye wrote:
>
>> I just ran into an odd and annoying problem - I'm building a Python
>> library/extension thing for a package (MapServer) and have a library
>> weak-linked (it's to a non-open source product, this is so others
>> don't have to install that if they don't need it and I don't have to
>> build multiple versions...).  Python's import seems to ignore that, I
>> suspect it's doing it's own library loading thing and checking all
>> symbols or something.
>>
>> Is this normal?  Is there a way to make Python NOT do it?  Or am I
>> stuck with it?
>
> I'm not entirely sure, I haven't tried it.  It uses these NSModule  
> flags to load extensions:
> 	NSLINKMODULE_OPTION_BINDNOW
> 	NSLINKMODULE_OPTION_RETURN_ON_ERROR
> 	NSLINKMODULE_OPTION_PRIVATE
>
> I don't believe that any of those options would defeat weak  
> linking, though.
>
> You might have to find the library at runtime with the dyld or dl  
> APIs and it use that way.  Or strong-link to it in a separate  
> extension that's only loaded if the library is detected.
>
It would be nice if MapServer had a simple plugin mechanism.  It's  
supposedly there, just not documented yet.

On Apr 11, 2006, at 9:54 PM, Saggau wrote:
> One way to say what I'm thinking:
>
> There might be another way around this.  It's another way of using  
> two modules, which might not be desirable, but not quite the "two  
> versions of the same thing, one with expanded functionality" type.   
> Instead, it's "Two different (and more basic/plain-Jane) library  
> wrappers, one wrapping just the third party code functionality and  
> one wrapping just my code functionality."  You can then test for  
> the existence of the third party code wrapper module and make your  
> python code behave accordingly.
>
> Another way:
>
> You could build one wrapper module that is only the third party  
> stuff and one that is only your code.  Then you could use two  
> imports in your python code, setting a variable or just testing  
> whether to use the "with extras" version of your python code or the  
> "stripped down" version.  That way, you can ship either load both  
> bundles or the one bundle depending on what the user's system has.   
> Am I making any sense?  I suspect not.
>
I understand what you're saying, I'm just not enough of a programmer  
to do such a thing.

> My-big-architectural-question (TM) is:
>
> If you know you're either going to have to deal with ifndef etc etc  
> in your big module code or the equivalent test to see if the little  
> third party module is loaded in your python code.  Either way,  
> you'll have to adjust what you're doing somewhere in code.  I have  
> found, with the caveat that I have limited experience with this,  
> that writing multiple very simple and low-level loadable bundles /  
> libraries with a thimbleful of functionality in each and letting  
> python be happily dynamic about what gets imported is easier than  
> trying to do the "I need to test if I can use this library or not"  
> in a big loadable bundle / library.
>
> In other words, I know where I would rather write my most dynamic  
> code.  Python.  :)  It's just easier to do there and I'm lazy.
>
For those that use the python version of MapServer, they would not  
use the functionality in their python code of the extra optional  
external library if they don't need it.  I know, kinda fragile.  But  
it works well enough in the CGI and PHP versions.


I guess I should just figure out the MapServer plugin thing.  I was  
hoping I could wait until some documentation was written.

-----
William Kyngesburye <kyngchaos at kyngchaos.com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.