Non-standard native library names

[flit]

CPM uses apparently non-standard native library names. On Posix systems the name is _native__lib.so, while on Windows it looks like _native__lib.cp37-win_amd64.pyd.

This is only a problem because PyInstaller expects libraries to match one of the following globs: *.dll, *.dylib, lib*.pyd, and lib*.so. So basically, libs with .so and .pyd extensions are expected to have a "lib" prefix.

I've worked around it in the PyInstaller .spec file for pyOCD, but thought it was worth mentioning.

[theotherjimmy]

That's worth looking into. Good to know that it should start with lib on POSIX(mac and Linux exhibit this behavior?). Since you mentioned that you are able to work around this, I'm not going to mark this priority or hold up the next release until we have a solution.

[cederom]

+FreeBSD / *BSD is POSIX :-P

[theotherjimmy]

I tried a quick diff:

diff --git a/cmsis_pack_manager/__init__.py b/cmsis_pack_manager/__init__.py
index db7887e35..a2d3ab3ec 100644
--- a/cmsis_pack_manager/__init__.py
+++ b/cmsis_pack_manager/__init__.py
@@ -21,7 +21,7 @@ from shutil import rmtree
 from json import load
 from zipfile import ZipFile
 from appdirs import user_data_dir
-from ._native import ffi, lib
+from .lib_cmsis_native import ffi, lib


 class _RaiseRust(object):
diff --git a/setup.py b/setup.py
index ca0c36516..cee637dfd 100644
--- a/setup.py
+++ b/setup.py
@@ -27,7 +27,7 @@ def build_native(spec):
     )

     spec.add_cffi_module(
-        module_path='cmsis_pack_manager._native',
+        module_path='cmsis_pack_manager.lib_cmsis_native',
         dylib=lambda: build.find_dylib('cmsis_cffi',
                                        in_path='target/release/deps'),
         header_filename=lambda: build.find_header('cmsis.h', in_path='cmsis-cffi')

which does not seem to resolve the issue:

cpm> unzip -l dist/cmsis_pack_manager-0.1.1-py2.py3-none-linux_x86_64.whl
Archive:  dist/cmsis_pack_manager-0.1.1-py2.py3-none-linux_x86_64.whl
  Length      Date    Time    Name
---------  ---------- -----   ----
    13490  2019-05-29 16:43   cmsis_pack_manager/__init__.py
     2305  2019-05-29 16:43   cmsis_pack_manager/_lib_cmsis_native__ffi.py
 66464272  2019-05-29 16:32   cmsis_pack_manager/_lib_cmsis_native__lib.so
      194  2019-05-29 16:32   cmsis_pack_manager/_native.py
     2295  2019-05-29 16:32   cmsis_pack_manager/_native__ffi.py
 66464272  2019-05-29 16:32   cmsis_pack_manager/_native__lib.so
      214  2019-05-29 16:43   cmsis_pack_manager/lib_cmsis_native.py
     8373  2019-04-09 15:38   cmsis_pack_manager/pack_manager.py
       71  2019-05-29 16:43   cmsis_pack_manager-0.1.1.dist-info/entry_points.txt
       19  2019-05-29 16:43   cmsis_pack_manager-0.1.1.dist-info/top_level.txt
      129  2019-05-29 16:43   cmsis_pack_manager-0.1.1.dist-info/WHEEL
      275  2019-05-29 16:43   cmsis_pack_manager-0.1.1.dist-info/METADATA
     1211  2019-05-29 16:43   cmsis_pack_manager-0.1.1.dist-info/RECORD
---------                     -------
132957120                     13 files

The _ prefix is still present. It's like they want to keep it private...

[theotherjimmy]

It seems that this behavior is baked into milksnake's setuptools extension: https://github.com/getsentry/milksnake/blob/master/milksnake/setuptools_ext.py#L217-L218. Perhaps I should report an issue on their bug tracker and/or submit a PR to fix this issue.

[0Grit]

Seems like there is a new python dependency issue every couple of days....

[0xc0170]

It seems that this behavior is baked into milksnake's setuptools extension: https://github.com/getsentry/milksnake/blob/master/milksnake/setuptools_ext.py#L217-L218. Perhaps I should report an issue on their bug tracker and/or submit a PR to fix this issue.

Has there been any progress?

Seems like there is a new python dependency issue every couple of days....

We should look at how to test these dependencies

cc @ARMmbed/mbed-os-test

[theotherjimmy]

Has there been any progress?

Nope

We should look at how to test these dependencies

I'm confused. This is not a "testing" problem really.

[AKJ7]

Yeah, we are in 2022 and this problem still exists. This problem and the solution are already given above. Can someone merge it or something?