Re: pybuild renaming extensions breaks upstream code
Hi Afif,
On Sun, Jul 03, 2016 at 02:37:41AM -0700, Afif Elghraoui wrote:
> It's a Python extension as far as I know. After investigating this a bit
> more, it seems that numpy's ctypeslib.load_library function can guess
> the library's extension. So for the unit test (before dh-python has
> renamed anything and the library is still librarybasename.so), it can
> guess properly if it's called as
>
> numpy.ctypeslib.load_library("librarybasename","/path/to/library/")
>
> but this won't work afterwards.
If it *is* a Python extension, you can simply import it and get the path
using the __path__ attribute.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Re: pybuild renaming extensions breaks upstream code
Hi, Dmitry,
Thanks for your reply
على السبت 2 تـمـوز 2016 23:03، كتب Dmitry Shachnev:
>> Is there a better way around this problem?
> If it is not a Python extension but rather a generic plugin, you can tell
> dh_python2 not to touch it (i.e. via the -X flag), or better install it to
> some private directory different from dist-packages.
It's a Python extension as far as I know. After investigating this a bit
more, it seems that numpy's ctypeslib.load_library function can guess
the library's extension. So for the unit test (before dh-python has
renamed anything and the library is still librarybasename.so), it can
guess properly if it's called as
numpy.ctypeslib.load_library("librarybasename","/path/to/library/")
but this won't work afterwards. I instead get
File "/usr/lib/python2.7/dist-packages/numpy/ctypeslib.py", line
163, in load_library
raise OSError("no file with expected extension")
OSError: no file with expected extension
Would it be a good idea to patch numpy to also look for multiarch
strings in the suffix?
Many thanks and regards
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
signature.asc
Description: OpenPGP digital signature
Re: pybuild renaming extensions breaks upstream code
Hi Afif,
On Sat, Jul 02, 2016 at 04:20:11PM -0700, Afif Elghraoui wrote:
> Hello,
> I'm maintaining a set of python modules that have this pattern of code
> for finding compiled extensions (this example is from the kineticstools
> package):
>
> [...]
>
> When the package is built and the architecture is renamed:
>
> I: dh_python2 fs:322: renaming tree_predict.so to
> tree_predict.x86_64-linux-gnu.so
>
> the upstream code breaks. What I've done in the past is patch it so that
> it searches for the extension the way we rename it (which I get using
> sysconfig.get_config_var('MULTIARCH')) as in the patch at
>
> http://anonscm.debian.org/git/debian-med/pbh5tools.git/tree/debian/patches/multiarch-module-path.patch
>
> Is there a better way around this problem?
If it is not a Python extension but rather a generic plugin, you can tell
dh_python2 not to touch it (i.e. via the -X flag), or better install it to
some private directory different from dist-packages.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
pybuild renaming extensions breaks upstream code
Hello,
I'm maintaining a set of python modules that have this pattern of code
for finding compiled extensions (this example is from the kineticstools
package):
~~~
if platform.system() == "Windows":
libfn = "tree_predict.dll"
path = os.path.dirname(os.path.abspath(__file__))
windowsLib = path + os.path.sep + libfn
if os.path.exists(windowsLib):
self._lib = np.ctypeslib.load_library(libfn, path)
else:
raise Exception("can't find tree_predict.dll")
else:
DLL_PATH = _getAbsPath("tree_predict.so")
if os.path.exists(DLL_PATH):
self._lib = np.ctypeslib.load_library("tree_predict.so",
DLL_PATH)
else:
raise Exception("can't find tree_predict.so")
~~~
When the package is built and the architecture is renamed:
I: dh_python2 fs:322: renaming tree_predict.so to
tree_predict.x86_64-linux-gnu.so
the upstream code breaks. What I've done in the past is patch it so that
it searches for the extension the way we rename it (which I get using
sysconfig.get_config_var('MULTIARCH')) as in the patch at
http://anonscm.debian.org/git/debian-med/pbh5tools.git/tree/debian/patches/multiarch-module-path.patch
Is there a better way around this problem?
Many thanks and regards
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
