Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #8627 > unrolled thread

pybuild renaming extensions breaks upstream code

Back to article view | Back to linux.debian.maint.python

Contents

  pybuild renaming extensions breaks upstream code Afif Elghraoui <afif@debian.org> - 2016-07-03 01:40 +0200
    Re: pybuild renaming extensions breaks upstream code Dmitry Shachnev <mitya57@debian.org> - 2016-07-03 08:30 +0200
      Re: pybuild renaming extensions breaks upstream code Afif Elghraoui <afif@ghraoui.name> - 2016-07-03 12:00 +0200
        Re: pybuild renaming extensions breaks upstream code Dmitry Shachnev <mitya57@debian.org> - 2016-07-04 17:30 +0200

#8627 — 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

[toc] | [next] | [standalone]

#8628

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#8629

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#8636

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web