[Bf-python] Loading shared library in Blender Python

[Arnaud Degroote]

On 17/Jun - 19:23, Christopher Barry wrote:
> On Wed, 17 Jun 2015 16:53:56 +0200
> Arnaud Degroote <arnaud.degroote at laas.fr> wrote:
> 
> >On 17/Jun - 15:59, Sybren A. Stüvel wrote:
> >> Hi Pierrick,
> >> 
> >> On Wed, Jun 17, 2015 at 03:49:23PM +0200, Pierrick Koch wrote:
> >> > I'd like to imort python package from ubuntu distribution into
> >> > blender. Their shared object extension is
> >> > .cpython-34m-x86_64-linux-gnu.so, while Blender look for
> >> > .cpython-34m.so (without "-x86_64-linux-gnu").
> >> 
> >> How did you gather this knowledge? It helps a lot to see what you're
> >> actually doing.
> >
> >To be more precise, what we try is doing
> >
> >import numpy
> >
> >which fails with 
> >
> >ImportError: cannot import name 'multiarray'
> >
> >(whole discussion is here :
> >https://github.com/morse-simulator/morse/pull/630)
> >
> >It basically fails because python from Ubuntu is built with multiarch
> >option and so the libraries have extension
> >cpython-34m-x86_64-linux-gnu.so. It is not the case of the python
> >embedded in binary blender.
> >
> >Of course, it is always possible, in this case, to use the numpy copy
> >from blender (but it is not a generic solution), or to hack the
> >filesystem (but it is cumbersome for users).
> >
> >Best regards,
> 
> Actually the symlink solution presented in the text you removed on
> reply is the typical 'behind the scenes' way this kind of thing usually
> gets done by the package manager at install time, using the packages'
> postinst script (in debian-derived distributions anyway). 
> 
> In a terminal run:
> 
> $ ls -la /{usr/,}lib{,64}
> 
> on your ubuntu box to see a good example of how prevalent this method
> is with system libraries.
> 
> also:
> 
> $ man update-alternatives
> 
> for how this methodology is used also for command aliasing and
> prioritizing.
> 
> try:
> 
> $ update-alternatives --display java
> 
> to see how java is configured, and
> 
> $ for a in $(update-alternatives --get-selections \
>   | awk '{ print $1 }'); do
>        update-alternatives --display "$a"; 
>        echo;
>   done | less
> 
> to see how all commands with alternatives are setup.
> 
> 
> So, it's really not a filesystem 'hack', it's a convenient and simple
> way that works for all programs and libs.

Well, for system-use, I agree. 
The easy solution would be to link 

multiarray.cpython-34m-x86_64-linux-gnu.so -> multiarray.cpython-34m.so

but it defeats completely the multiarch work (and it requires root access).

Linking only the .egg somewhere in $HOME won't help, because it properly
finds numpy in the system.

The last solution requires to link all the numpy files (with the good
name) one by one somewhere in $HOME, with the right hierarchy (because
of all the relative import). For standard users, it looks hard (of
course, if all the users understand Unix, the World would be so much easier
:)). We can provide of course a "smart enough" script to do that, but
how long will be smart enough to handle differences between
distributions / packages version ?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20150618/f3bc8172/attachment.sig>