Same problem here with IUSaveConfigText. I can install the package with pip3 but I get the error above when importing PyIndi.
I went a little further and I saw that actually the symbol IUSaveConfigText exists in _PyIndi.cpython-38-x86_64-linux-gnu.so


Ubuntu 20.04.2 LTS
INDI Library: 1.8.8
Python 3.8

Same problem here with IUSaveConfigText, I can install the package but I get the error above when importing PyIndi.
I went a little further and saw that actually the symbol IUSaveConfigText exists in _PyIndi.cpython-38-x86_64-linux-gnu.so


Ubuntu 20.04.2 LTS
INDI Library: 1.8.8
Python 3.8

I hit the same issue today on ARM (Raspberry Pi 4B+). I also noticed that pyindi-client master does not build against indi master right now and I had to roll back indi to the most recent tag to make it build. In my case I think I can roll-back to v1.8.5, so that's probably what I will do. But you're right that this is a problem and I too encountered it.

(PS: I built all packages from source, including pyindi-client)

Just in case anyone else encounters this and can rollback to a different version of INDI unlike OP, rolling back to v1.8.6 (both on indi and indi-3rdparty) worked for me. pyindi-client was built from master.

I haven't yet found a clean solution to this problem. Seems to by a bug in the new libraries? Anyone knows where should I report it?
I do have a workaround: I can install PyIndi via pip before adding the PPA with the new versions of the libraries and then, only after installing PyIndi, update to the PPA and install the drivers for my CCD. Doing this PyIndi imports and works ok (I guess it is build against the old libraries?) and I have the drivers for the CCD.

Same problem here, ubuntu 20.04 on x86

I am still having this problem, but I have a messy workaround.
If I install PyIndi via pip *before* installing the PPA (and, thus using the libraries provided by Ubuntu, v1.8.5) the import works. I am then able to install the PPA, update the libraries and install the drivers of my CCD and everything seems to continue to work OK.
However, I think this is a bug that needs to be solved. Anyone knows where to report it?

I would assume here: github.com/indilib/indi/issues
and
github.com/geehalel/pyindi-client/issues

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

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

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
This tries to compile against libindi-1.8.9-16_gd6e9d74a. Full install log attached, if someone's interested.

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.