search

dftlibs / xcfun

XCFun: A library of exchange-correlation functionals with arbitrary-order derivatives
https://dftlibs.org/xcfun/
Mozilla Public License 2.0
58 stars 32 forks source link

Suggestion: Port Python interface from SWIG to either CFFI or pybind11 #44

Closed bast closed 4 years ago

bast commented 6 years ago

In my opinion SWIG is not the optimal framework. CFFI and pybind11 are more lightweight IMO.

aspgomes commented 6 years ago

i can look into that. if possible, it would be good to have a single framework for all dftlibs projects, so @bast are you sticking to cffi for numgrid ?

robertodr commented 6 years ago

I vote for pybind11.

On Dec 19, 2017 16:09, "Andre Gomes" notifications@github.com wrote:

i can look into that. if possible, it would be good to have a single framework for all dftlibs projects, so @bast https://github.com/bast are you sticking to cffi for numgrid ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dftlibs/xcfun/issues/44#issuecomment-352786271, or mute the thread https://github.com/notifications/unsubscribe-auth/ADiXEb5HzA9kYxN1LByifP4WHWim1eA2ks5tB9GvgaJpZM4RHFz7 .

aspgomes commented 6 years ago

thanks for speaking out @robertodr . @bast @chjacob-tubs and others interested in python bindings, can you speak your mind ?

robertodr commented 6 years ago

To motivate a bit. In my opinion (and I've mentioned this to @bast before) CFFI really shines when you have a C or Fortran code that you want to expose to Python. Since XCFun is C++, I think it's more appropriate and beneficial to jump to C++11 (required by pybind11) and base the Python API on the C++ API, rather than on the C flattening of it. Advantages of pybind11 are:

  1. STL containers are bound to the appropriate Python objects automagically.
  2. One can interchange numpy arrays with C arrays (requires a bit more work, to avoid mishaps with garbage collection, but it's definitely doable)

So, to conclude: I think the code should have a main C++ API to which the API for other languages are bound and modelled on. The C API should be the trampoline for a native Fortran API, not the main gig.

On Dec 19, 2017 16:28, "Andre Gomes" notifications@github.com wrote:

thanks for speaking out @robertodr https://github.com/robertodr . @bast https://github.com/bast @chjacob-tubs https://github.com/chjacob-tubs and others interested in python bindings, can you speak your mind ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dftlibs/xcfun/issues/44#issuecomment-352792121, or mute the thread https://github.com/notifications/unsubscribe-auth/ADiXEa8DitC2mOsHG5PiSNFAMvNVQuPnks5tB9YRgaJpZM4RHFz7 .

bast commented 6 years ago

I agree that here pybind11 is probably the best way. I like CFFI for projects that use a C interface. The question for me boils down to whether we wish to expose a C++ interface. If yes, then pybind11. If not, then CFFI. But before we do anything we need to reactivate the current Python interface and add tests to it (#43).

sunqm commented 6 years ago

Don't know whether you plan to port xcfun to PyPI. If so, CFFI is probably better. The pybind11 dependence is quite difficult to solve.

bast commented 6 years ago

My plan is to distribute the code also via PyPI. Why is the pybind11 dependence a problem? [I have never tried to distribute pybind11 code via PyPI]

sunqm commented 6 years ago

I may be wrong. pybind11 is available on PyPI. Just a suggestion to consider before choosing the technique.

chjacob-tubs commented 6 years ago

I am happy with everything, just keep me in the loop so I can test it with PyADF / PyEmbed

robertodr commented 4 years ago

Closing, as we moved to pybind11 with #96 The deployment to PyPI is still not a thing, but I have been looking at deploying on Anaconda cloud (conda-forge/staged-recipes#10347) with mixed success, so far.