python depend failed

[mintuos]

Environment Information

Open Babel version: 3.1.1
Operating system and version: centos7

Expected Behavior

cmake -DWITH_MAEPARSER=OFF -DWITH_COORDGEN=OFF -DPYTHON_BINDINGS=ON -DRUN_SWIG=ON ..

when I use cmake install openbabel or use yum, all of this is ok.
but when -DPYTHON_BINDINGS is ON
there was a error in make(cmake is no error)

Actual Behavior

when make progress 99%
there is a error

[ 99%] Generating ../../scripts/python/openbabel/openbabel-python.cpp, ../../scripts/python/openbabel/openbabel.py
/home/ji/ha/openbabel/scripts/openbabel-python.i:80: Error: Syntax error in input(1).
make[2]: *** [../scripts/python/openbabel/openbabel-python.cpp] Error 1
make[1]: *** [scripts/CMakeFiles/bindings_python.dir/all] Error 2
make: *** [all] Error 2

python.i:80:

// Set and reset dlopenflags so that plugin loading works fine for "import _openbabel"
%pythonbegin %{
import sys
if sys.platform.find("linux") != -1:
    dlflags = sys.getdlopenflags()
    import ctypes
    sys.setdlopenflags(dlflags | ctypes.RTLD_GLOBAL)
%}
%pythoncode %{
if sys.platform.find("linux") != -1:
    sys.setdlopenflags(dlflags)
%}

---

I think the openbabel did not use correct python, or the linux version is too old?

[welcome]

Thanks for opening your first issue here! Be sure to follow the issue template!

[nbehrnd]

I speculate your setup attempts to fetch openbabel from pypi.org instead of the OS' package manager. If this is the case, check if the by bypass with openbabel-wheel equally works for you. This works out of the box e.g., within a virtual environment set up in Linux Debian 13/trixie when installing openbabel via ```shell pip install -r ./requirements.txt ``` Its current update was published in October 2023.

[mintuos]

I speculate your setup attempts to fetch openbabel from pypi.org instead of the OS' package manager. If this is the case, check if the by bypass with openbabel-wheel equally works for you. This works out of the box e.g., within a virtual environment set up in Linux Debian 13/trixie when installing openbabel via shell pip install -r ./requirements.txt Its current update was published in October 2023.

Sorry, I'm a beginner in this field and I don't understand what you mean.Could you explain it in more detail?

 pip list
Package         Version
--------------- --------
colorama        0.4.6
exceptiongroup  1.2.0
iniconfig       2.0.0
openbabel-wheel 3.1.1.19
packaging       23.2
pip             23.3.1
pluggy          1.3.0
pytest          7.4.3
setuptools      68.2.2
tomli           2.0.1
wheel           0.41.2

i use openbabel-wheel with new try,and delete build cache, but the error was same,

this is my code

cmake -DWITH_MAEPARSER=OFF -DWITH_COORDGEN=OFF -DPYTHON_BINDINGS=ON -DRUN_SWIG=ON  -DPYTHON_EXECUTABLE=/home/jf/Programs/anaconda3/envs/gnina/bin/python ..

thank you

[nbehrnd]

The following can only cover some parts.

Inferring from Linux Debian, Linux CentOS provides some basic support of Python; mainly to support the operating system itself. And if you perform a proper update of the operating system, then equally these supporting libraries are going to be updated.

Now to your project. There is a set of modules deemed essential to Python; they constitute the Python standard library every Python installation includes, for instance os, sys, argparse. See for instance here and here.

Additional functionality can be imported by additional libraries. One way to manage these new dependencies is by a requirements.txt file to list these modules -- preferably with indication of their (minimal) version known to work. For example

CairoSVG>=2.7.1
openbabel-wheel>=3.1.1.16
rdkit>=2023.3.2
Requests>=2.31.0

To keep the Python libraries which support your operating system in good shape, it is considered good practice to keep them separate (not accidentally modified) from packages used to develop and experiment with new packages. This is the background of using virtual environments which you

• first create, i.e. set up of a minimal clean Python environment

• second activate, i.e. to start using them

• third complement by additional Python packages (if needed) to provide additional functionality. Here the special file requirements.txt helps you because

  pip install -r ./requirements.txt

  is going to resolve the dependencies for you automatically.

  In case virtual environments is a concept new to you, Python documents it here. Real Python offers a free primer less technical if you prefer so. In each case: note that the commands in Windows, Linux, MacOS to toggle on/off the virtual environment differ of each other. The advantage of this development separate from the libraries used by your operating system: you don't harm your OS. If you are stuck in an error, deactivate the virtual environment, delete the whole folder of this virtual environment, and start all over from scratch.

  Obviously, for your project, you have to identify and use your project's requirements.txt. If there is no requirements.txt, get in touch with the author of the application. Else, set up a virtual environment, activate it and install pipreqs to quickly generate a requirements.txt about all non-standard Python modules your project requires. But: pipreqs does not know about openbabel-wheel -- which is why a manual edit in requirements.txt is necessary. Try then if your application can be started and used as described by its documentation.

An aspect specific point to openbabel (from pypi.org) and openbabel-wheels (from pypi.org): openbabel-wheels as a bypass aims to install where normally openbabel would be. In case you already installed openbabel in your virtual environment, you then must deinstall openbabel (by the command pip remove openbabel) in first place before an installation of openbabel-wheel is successful.

Last but not least I see your cmake command. If you work with an activated virtual environment of Python, the address of the python interpreter is different from the usually used one. (Of course, because you do not want to harm your operating system.) So your command

which python

which normally points to /usr/bin/python* now (again, in the working/activated virtual environment of Python) points to a different location of your python interpreter within your virtual environment. Edit your command accordingly and use the address of the interpreter within the active virtual environment.

* which might be itself a symbolic link to the interpreter

[baloglu]

You may like to update your swig if you havent already. centos7 default repos have swig 2.0 and as far as I remember, recent versions of cmake require swig 4+, or at least work better.