Raise error or warning, if pythonfmu/resources/binaries/linux64/libpythonfmu-export.so is missing

[BenjaminRodenberg]

I installed pythonfmu by cloning this repository and using the provided setup.py script. On the first try I did not generate pythonfmu/resources/binaries/linux64/libpythonfmu-export.so. This led to unusable FMUs. I think it would be helpful to raise a error or warning, if a user tries to install pythonfmu via setup.py and libpythonfmu-export.so is missing.

Ideally one could entirely avoid running cmake and make and do everything in setup.py, but I have no idea whether this is possible, at all.

Current behavior (without libpythonfmu-export.so)

no libpythonfmu-export.so in ~/.local/lib/python3.8/site-packages/pythonfmu/

~/PythonFMU$ pip3 install --user .
Processing /home/benjamin/PythonFMU
Building wheels for collected packages: pythonfmu
  Building wheel for pythonfmu (setup.py) ... done
  Created wheel for pythonfmu: filename=pythonfmu-0.6.2-py3-none-any.whl size=34435 sha256=07d8754cb31d0e90cd8aa18fcb945a5ebb9be871b1ba6592f619eb8b4d5115c1
  Stored in directory: /tmp/pip-ephem-wheel-cache-m7xfnb8k/wheels/8a/74/0a/a66d0648873b0dc6cbc08d3ecdf5aee6f3fa271703b5d0fe3a
Successfully built pythonfmu
Installing collected packages: pythonfmu
  Attempting uninstall: pythonfmu
    Found existing installation: pythonfmu 0.6.2
    Uninstalling pythonfmu-0.6.2:
      Successfully uninstalled pythonfmu-0.6.2
Successfully installed pythonfmu-0.6.2
~/PythonFMU$ ls ~/.local/lib/python3.8/site-packages/pythonfmu/
builder.py  csvbuilder.py  default_experiment.py  deploy.py  enums.py  fmi2slave.py  __init__.py  logmsg.py  __main__.py  osutil.py  __pycache__  tests  variables.py  _version.py

Current behavior (with libpythonfmu-export.so)

if I run cmake etc. there is a libpythonfmu-export.so in ~/.local/lib/python3.8/site-packages/pythonfmu/

~/PythonFMU$ cd pythonfmu/pythonfmu-export/
~/PythonFMU/pythonfmu/pythonfmu-export$ mkdir build
~/PythonFMU/pythonfmu/pythonfmu-export$ cd build/
~/PythonFMU/pythonfmu/pythonfmu-export/build$ cmake ..
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Python3: /usr/bin/python3.9 (found version "3.9.0") found components: Interpreter Development 
Building pythonfmu-export for platform linux64
-- Configuring done
-- Generating done
-- Build files have been written to: /home/benjamin/PythonFMU/pythonfmu/pythonfmu-export/build
~/PythonFMU/pythonfmu/pythonfmu-export/build$ make
Scanning dependencies of target pythonfmu-export
[ 25%] Building CXX object CMakeFiles/pythonfmu-export.dir/cpp/cppfmu_cs.cpp.o
[ 50%] Building CXX object CMakeFiles/pythonfmu-export.dir/cpp/fmi_functions.cpp.o
[ 75%] Building CXX object CMakeFiles/pythonfmu-export.dir/cpp/PySlaveInstance.cpp.o
[100%] Linking CXX shared library /home/benjamin/PythonFMU/pythonfmu/resources/binaries/linux64/libpythonfmu-export.so
[100%] Built target pythonfmu-export
~/PythonFMU/pythonfmu/pythonfmu-export/build$ cd ~/PythonFMU/
~/PythonFMU$ pip3 install --user .
Processing /home/benjamin/PythonFMU
Building wheels for collected packages: pythonfmu
  Building wheel for pythonfmu (setup.py) ... done
  Created wheel for pythonfmu: filename=pythonfmu-0.6.2-py3-none-any.whl size=666965 sha256=17d2845dce4e571fd3e95ec7ea9170b38a91adad5f3149b9453c56fe81fd7091
  Stored in directory: /tmp/pip-ephem-wheel-cache-q2_azoq3/wheels/8a/74/0a/a66d0648873b0dc6cbc08d3ecdf5aee6f3fa271703b5d0fe3a
Successfully built pythonfmu
Installing collected packages: pythonfmu
  Attempting uninstall: pythonfmu
    Found existing installation: pythonfmu 0.6.2
    Uninstalling pythonfmu-0.6.2:
      Successfully uninstalled pythonfmu-0.6.2
Successfully installed pythonfmu-0.6.2
~/PythonFMU$ ls ~/.local/lib/python3.8/site-packages/pythonfmu/resources/binaries/linux64/
libpythonfmu-export.so

Expected behavior (without libpythonfmu-export.so)

Add a warning (or even abort), if there is no libpythonfmu-export.so.

~/PythonFMU$ pip3 install --user .
WARNING: cannot find libpythonfmu-export.so.
Processing /home/benjamin/PythonFMU
Building wheels for collected packages: pythonfmu
  Building wheel for pythonfmu (setup.py) ... done
  Created wheel for pythonfmu: filename=pythonfmu-0.6.2-py3-none-any.whl size=34435 sha256=07d8754cb31d0e90cd8aa18fcb945a5ebb9be871b1ba6592f619eb8b4d5115c1
  Stored in directory: /tmp/pip-ephem-wheel-cache-m7xfnb8k/wheels/8a/74/0a/a66d0648873b0dc6cbc08d3ecdf5aee6f3fa271703b5d0fe3a
Successfully built pythonfmu
Installing collected packages: pythonfmu
  Attempting uninstall: pythonfmu
    Found existing installation: pythonfmu 0.6.2
    Uninstalling pythonfmu-0.6.2:
      Successfully uninstalled pythonfmu-0.6.2
Successfully installed pythonfmu-0.6.2
~/PythonFMU$ ls ~/.local/lib/python3.8/site-packages/pythonfmu/
builder.py  csvbuilder.py  default_experiment.py  deploy.py  enums.py  fmi2slave.py  __init__.py  logmsg.py  __main__.py  osutil.py  __pycache__  tests  variables.py  _version.py

[markaren]

I agree that something like this could be implemented. However, I have no idea how realize it.

[HenningScheufler]

setuptools offers the possiblity to call commands before and after the packaging see pull request 136

[Jorgelmh]

The solution introduced by @jschueller in PR 188 breaks the pythonfmu functionality when running the python code from inside the FMU. This is because the path to the binaries is different depending on the context. The FmuBuilder.has_binary function is meant to be used by the builder to check if the installation of pythonfmu has the needed binaries to create the FMU.

Running this code from inside the FMU will make the model fail while instantiating as the binaries are located in a different path within the FMU.

Note: When the FMU is simulated and the python code inside of it is run, it will use the pythonfmu code that is bundled into the FMU as opposed to the installed pythonfmu package that you usually find in your python environment. Therefore, we shouldn't check for the binaries to be in the resources folder.

We (DNV) need to release a new version of pythonfmu for a project, so I'll be deleting this check from the __init__.py hoping that we can fix this in the future.

[jschueller]

fine, I can also check the binary from outside pythonfmu for now
thanks for the new version