×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Problem importing PyIndi

  • Posts: 102
  • Thank you received: 13

Replied by dolguldur on topic Problem importing PyIndi

I tried removing all the unstable stuff comming from the ppa's And then installed ubuntu 20.04 stock indi-dev package
Know I am left with this:

ldd /home/user/venv/lib/python3.7/site-packages/_PyIndi.cpython-37m-x86_64-linux-gnu.so
linux-vdso.so.1 (0x00007ffda918b000)
libz.so.1 => /opt/anaconda3/lib/libz.so.1 (0x00007fbfb55b9000)
libcfitsio.so.8 => /usr/lib/x86_64-linux-gnu/libcfitsio.so.8 (0x00007fbfb5285000)
libnova-0.16.so.0 => /usr/lib/x86_64-linux-gnu/libnova-0.16.so.0 (0x00007fbfb4f06000)
libstdc++.so.6 => /opt/anaconda3/lib/libstdc++.so.6 (0x00007fbfb4dc5000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbfb4c76000)
libgcc_s.so.1 => /opt/anaconda3/lib/libgcc_s.so.1 (0x00007fbfb4c62000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbfb4c3d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbfb4a4b000)
libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007fbfb49bc000)
libbz2.so.1.0 => /opt/anaconda3/lib/libbz2.so.1.0 (0x00007fbfb47aa000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbfb56a2000)
libnghttp2.so.14 => /usr/lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007fbfb4781000)
libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0 (0x00007fbfb475e000)
librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x00007fbfb473e000)
libssh.so.4 => /usr/lib/x86_64-linux-gnu/libssh.so.4 (0x00007fbfb46d0000)
libpsl.so.5 => /usr/lib/x86_64-linux-gnu/libpsl.so.5 (0x00007fbfb46bd000)
libnettle.so.7 => /usr/lib/x86_64-linux-gnu/libnettle.so.7 (0x00007fbfb4683000)
libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007fbfb44ad000)
libgssapi_krb5.so.2 => /opt/anaconda3/lib/libgssapi_krb5.so.2 (0x00007fbfb445c000)
libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007fbfb4406000)
liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007fbfb43f5000)
libbrotlidec.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007fbfb43e7000)
libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2 (0x00007fbfb4265000)
libhogweed.so.5 => /usr/lib/x86_64-linux-gnu/libhogweed.so.5 (0x00007fbfb422b000)
libgmp.so.10 => /opt/anaconda3/lib/libgmp.so.10 (0x00007fbfb3f97000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fbfb3cc1000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007fbfb3b8b000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007fbfb3b75000)
libkrb5.so.3 => /opt/anaconda3/lib/./libkrb5.so.3 (0x00007fbfb3a99000)
libk5crypto.so.3 => /opt/anaconda3/lib/./libk5crypto.so.3 (0x00007fbfb3a78000)
libcom_err.so.3 => /opt/anaconda3/lib/./libcom_err.so.3 (0x00007fbfb3a72000)
libkrb5support.so.0 => /opt/anaconda3/lib/./libkrb5support.so.0 (0x00007fbfb3a63000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbfb3a5d000)
libcrypto.so.1.0.0 => /opt/anaconda3/lib/./libcrypto.so.1.0.0 (0x00007fbfb3814000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fbfb37f8000)
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007fbfb37d9000)
libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007fbfb3794000)
libbrotlicommon.so.1 => /usr/lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007fbfb3771000)
libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7 (0x00007fbfb3765000)
libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007fbfb3759000)
libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007fbfb36c4000)
libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007fbfb361d000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007fbfb3616000)
libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007fbfb35de000)
libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007fbfb35c5000)
libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007fbfb359b000)
libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007fbfb3587000)
libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007fbfb3539000)
libsqlite3.so.0 => /opt/anaconda3/lib/libsqlite3.so.0 (0x00007fbfb3414000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007fbfb33d9000)

(no trace of libindi whatsoever)

nm -D /home/user/venv/lib/python3.7/site-packages/_PyIndi.cpython-37m-x86_64-linux-gnu.so | grep IUSaveConfigText
U IUSaveConfigText

The sybol seems undefined here. But you can find it in
nm -D /usr/lib/x86_64-linux-gnu/libindidriver.so | grep IUSaveConfigText
0000000000035dd3 T IUSaveConfigText

But not much in the static client library:
nm /usr/lib/x86_64-linux-gnu/libindiclient.a | grep Save
0000000000002821 T IUSaveText
U IUSaveText
U IUSaveText
Last edit: 3 years 1 month ago by dolguldur.
3 years 1 month ago #66895

Please Log in or Create an account to join the conversation.

  • Posts: 102
  • Thank you received: 13

Replied by dolguldur on topic Problem importing PyIndi

There seems to be other things that are not right with 1.8.8 and 1.8.9:
Here is what I get trying to install pyindi with version older than 0.2.6 ie 0.2.5 and earlier :

<code>pip install pyindi-client==0.2.5; python -c "import PyIndi"
</code>
:
At this line, there is a macro:
<code>class Property
{
DECLARE_PRIVATE(Property)
public:
Property();
</code>

The macro is defined in indiutility.h
<code>#define DECLARE_PRIVATE(Class) \
inline Class##Private* d_func() { return reinterpret_cast<Class##Private *>(getPtrHelper(d_ptr)); } \
inline const Class##Private* d_func() const { return reinterpret_cast<const Class##Private *>(getPtrHelper(d_ptr)); } \
friend class Class##Private;
</code>

I think this is breaking swig

From github, it looks that those changes where made by pawel soja, and I am not sure wether the tests from the build platform includes swig compatibility (ie, building python bindings before accepting the PR), I doubt it:
github.com/indilib/indi/blob/master/libs/indibase/indiutility.h
Last edit: 3 years 1 month ago by dolguldur.
3 years 1 month ago #66918

Please Log in or Create an account to join the conversation.

  • Posts: 1009
  • Thank you received: 133
Maybe some comments:
There are other programs/packages that have problems with pip-installed stuff. E.g., python-opencv installs binary libraries that will not run on recent systems (Tumbleweed, Fedora 33, Ubuntu 20.??). Then trying to run python code that imports it will crash. Does your 'pip install' also bring such precompiled .so libs?

I tried to install pyindi-client here (openSUSE Tumbleweed) using pip, but I cant even do that. It will download version 0.2.6 tar file and try to run the setup.py. First had to install swig (4.0.2), but then compiling will fail with
    indiclientpython_wrap.cpp: In function ‘PyObject* _wrap_Property_getNumber(PyObject*, PyObject*)’:
    indiclientpython_wrap.cpp:22067:3: error: ‘PropertyView’ was not declared in this scope; did you mean ‘INDI::PropertyView’?
    22067 |   PropertyView< INumber > *result = 0 ;

This tries to compile against libindi-1.8.9-16_gd6e9d74a. Full install log attached, if someone's interested.
3 years 1 month ago #66955
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 226
  • Thank you received: 88

Replied by Jean-Luc on topic Problem importing PyIndi

I just tried to build pyindi-client with latest indi core commit on up-to-date Ubuntu 20.04. That compiles fine but the testindiclient.py script crashes when trying to iterate over a switch property:
```
elif p.getType()==PyIndi.INDI_SWITCH:
tpy=p.getSwitch()
for t in tpy:
TypeError: 'SwigPyObject' object is not iterable
pure virtual method called
```
It seems that Property get* methods are pure virtual. Will have a more precise look to that later.
3 years 1 month ago #67034

Please Log in or Create an account to join the conversation.

  • Posts: 12
  • Thank you received: 0

Replied by James on topic Problem importing PyIndi

Getting similar problems trying to use even basic basic PyIndi stuff - connection works but trying to update parameters I get the same subscriptable error.
None of the example scripts in the docs work except the basic "import, connect, and do nothing" one.

So yeah, PyIndi appears completely broken right now on 1.8.9. I've been trying to write a Rust INDI client which can provide a Python binding because the current state of PyIndi isn't great (and on other platforms like Windows it's a challenge), but it's a lot of effort to get that working.
3 years 1 week ago #68892

Please Log in or Create an account to join the conversation.

  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:Problem importing PyIndi

First, go python3. Then, because there are changes in the structure of indi in progress, please be patient with the maintainer of pyindi, or offer to debug more deeply. Thanks!

-Eric
3 years 1 week ago #68894

Please Log in or Create an account to join the conversation.

  • Posts: 12
  • Thank you received: 0

Replied by James on topic Re:Problem importing PyIndi

I'm using Python 3.

I am completely up for pitching in on pyindi if I can figure out how - I just wanted to confirm that the issue seen above was not isolated and was current.

My main gripe with pyindi is the documentation - if there are major changes underway that's okay, I know docs are often the last thing to get updated (being a maintainer for some OSS myself) but it doesn't help newbies (like me!) coming into an ecosystem if the basic examples explode with the "correct" config/setup/etc.

Edit: In the spirit of debugging "more deeply" - the issue appears that the attrs (value) referenced in the docs on the property returned by a device.getNumber() call (and from the looks of it, other similar calls) don't exist any more. The returned object is a INDI::PropertyView SWIG wrapper which has essentially no attributes or functions outside of the generic SWIG ones. This means you can't alter e.g. an exposure time value before returning it with sendNewNumber.

Without modifying the value, the sendNewNumber function additionally crashes with the following:
Traceback (most recent call last):
  File "allsky/allsky.py", line 91, in <module>
    asc.sendNewNumber(camera_exposure)
  File "/usr/local/lib/python3.7/dist-packages/PyIndi.py", line 1147, in sendNewNumber
    return _PyIndi.BaseClient_sendNewNumber(self, *args)
NotImplementedError: Wrong number or type of arguments for overloaded function 'BaseClient_sendNewNumber'.
  Possible C/C++ prototypes are:
    INDI::BaseClient::sendNewNumber(INumberVectorProperty *)
    INDI::BaseClient::sendNewNumber(char const *,char const *,char const *,double)
Last edit: 3 years 1 week ago by James.
3 years 1 week ago #68896

Please Log in or Create an account to join the conversation.

  • Posts: 27
  • Thank you received: 32
This happened a lot before, and it's definitely gonna happen again.
As much as I appreciate the pyindi-client project, it's essentially just a workaround for automatic API generation.

I have to wonder if it wouldn't just be easier to write a native python client for the XML protocol, or possibly a c++ python wrapper exposing a simplified version of the API...
The following user(s) said Thank You: dolguldur
3 years 15 hours ago #69365

Please Log in or Create an account to join the conversation.

  • Posts: 12
  • Thank you received: 0

Replied by James on topic Re:Problem importing PyIndi

I've been working on a Rust-native client that has no dependency on libindi, specifically because I want something portable; in theory it would be quite easy to provide a Python extension with the Rust backend.

Having said that, a pure Python client would be much easier to write (I'm struggling with INDI because of the poor state of XML parsers in Rust) and in theory to maintain given the wider Python userbase. For client authoring it'd certainly be easier to work with. I'm writing this purely to drive an all-sky camera and that'll be shipping images off to a neural net/CV stuff for image segmentation, and Python's a native of that sort of thing.
3 years 13 hours ago #69371

Please Log in or Create an account to join the conversation.

  • Posts: 27
  • Thank you received: 32
I would be afraid that the Rust-based python extension would have similar problem..
Not that I don't trust your work, but given that not many people know Rust, it would be difficult to find someone helping you maintain it :\

Ideally, the best solution would be a simplified JSON interface written in C++ directly into the INDI server. That way, writing a client for python, or indeed any other language, would be much much simpler
3 years 13 hours ago #69372

Please Log in or Create an account to join the conversation.

  • Posts: 102
  • Thank you received: 13
There seems to be already some work made in that direction:
github.com/geehalel/npindi
github.com/MMTObservatory/indiclient/tree/master/indiclient

I definitely agree that a full python solution would eventually be the best choice for long term support.
Cases where people will write exotic macros here and there that will probably continue break swig (without even considering the static binary dependency for the client)
Last edit: 2 years 11 months ago by dolguldur.
2 years 11 months ago #69414

Please Log in or Create an account to join the conversation.

  • Posts: 27
  • Thank you received: 32
That is good to know!
I was actually about to start my own implementation, but if I can find the time I might try to contribute to one of these.
geehalel implementation seems more mature, but also inactive in a couple of years.
@Jean-Luc do you have any insight on this?
is there a way to tag someone in this forum? 
Last edit: 2 years 11 months ago by Marco Gulino.
2 years 11 months ago #69420

Please Log in or Create an account to join the conversation.

Time to create page: 0.885 seconds