[python] Use new Python module structure of dune-common MR 960

@samuel.burbulla Could you have a look at this?

resolved all threads

added 1 commit

9c2ad3e6 - Apply 1 suggestion(s) to 1 file(s)

@tkoch does this work? I would have thought the subpackage folder python/dune/foamgrid needs a __init__.py (only dune itself is not allowed to have an __init__.py file using the newer namespace package syntax). But perhaps I am wrong here.

I would rename foamgrid.py into __init__.py anyway (or have an __init__.py with an from foamgrid import * so that you don't have to write from dune.foamgrid.foamgrid import ... in your own script.

Another thing: you shouldn't need the setup.py.in except if you are doing something special there. Or is this included to make the code work with both core and release branch of core. In that case you might need to include __init__.py in dune/python (although @samuel.burbulla said that using release core worked with dune-mmsh so possibly it's okay). If it is needed you will need to guard the add_python_targets with the version of dune-common.

I don't think it works. I just don't have that much time for proper testing right now and I'm a bit lost on what to do if I want to be compatible with 2.8 and master. Dumux seems to require foamgrid bindings for some reason, haven't figured out why that is now necessary.

the init thing makes sense. thanks

added 1 commit

80493690 - [python] Use new Python module structure of dune-common MR 960

Compare with previous version

The problem might simply be that if there is a python subfolder in a given module and python bindings are turned on then that module is treated as having python bindings and the system will try to include that module in the installation process. So if dumux has python bindings turned on and uses dune-foamgrid then the dune-foamgrid bindings have to comply with the structure expected in 'dune-common'.

In the last dev meeting it was decided that python bindings were so new that a break in the way python bindings are handled was acceptable. The issue that you are seeing was not foreseen at the time.

Samuel said he got his module to work with both master and release of dune-common so it must be possible. It might require including the 'setup.py.in' and the 'python/dune/init.py' but have the corresponding lines in 'CMakeLists.txt' guarded by an 'if' statement that checks if 'dune-common' has major version 2.8.