Maintaining bindings

[rubiop]

I think we now have a good understanding of how to build bindings for Julia,Python and Matlab. While some bindings might be less "automatic" than others, I was wondering how overall we can ensure that the bindings will keep up with the development of the main C++ code.

I guess one idea is to build tests that are comparable between C++ and other languages. As we don't necessary want to expose every class to the bindings I guess we would want to do this with a specific set of tests.

Will it be possible to automatically create binding issues each time an important feature/modification we need to expose to bindings is merged to the main?

Also regarding binding maintenance, I think we should write tutorials for bindings. While pybind11 tutorials probably already exists, I would love to have a specific tutorial for MParT that I can easily find that explains how to proceed with the specific class/files/library of the project so I can contribute easily. Regarding Matlab bindings I thinks it's absolutely necessary. I had big trouble finding something already existing and the solution I am using is kind of homemade and requires explanation so that other people would be able to contribute (or improve!!).

Let me know if any of this makes sense or if you have any ideas!

[mparno]

I love the idea of step-by-step instructions for how to add a binding for each language. This could easily be added to the sphinx documentation in the docs folder. We could actually create a new folder for all the stuff that developers might want to know: how to add bindings, etc...

In terms of making sure that the bindings are updated as we add capabilities to MParT, maybe we could create some sort of checklist that pull request reviewers need to go through (maybe something like this). Checking to make sure the bindings have been updated could be part of the checklist.

[bonh]

Making bindings mandatory might hinder the development of core cpp code, because that would require a developer to write code in cpp, python, Julia, and Matlab?! Therefore I am more in favor of an asynchronous approach or implement-by-need (trademark pending). In that way the cpp functionalities can progress without bindings and bindings are added when needed by user code. In addition, before a major release, we can walk through the cpp code and add missing bindings.

[rubiop]

Yes, I agree that doesn't make sense for a contributor to the main library to be required to do the bindings. However, I think it's still important that the discrepancies between C++ capabilities are emphasized. That makes easier for the binding people to know where they at and for the users to know what capabilities are available or not in their language of choice. Also it depends of what we consider the code to be. If it is mainly a c++ code with binding capabilities that is fine to have a c++ code more advanced than the binding options. However, if we don't think that the code will be mainly used in c++ but with other languages I think everything should be up to date with every bindings when pushed on the main branch.

In any case, if we can find a feature and/or a good habit to clearly specify the list of what has to be done in the bindings each time a C++ modification is done, that would be great. Then we can decide if we want this list to be completed before merging to main or not.

[bonh]

If it is mainly a c++ code with binding capabilities that is fine to have a c++ code more advanced than the binding options.

That really is worth thinking about!

if we don't think that the code will be mainly used in c++ but with other languages I think everything should be up to date with every bindings when pushed on the main branch

I think that the code will be used from other languages but I am curious about what the others think.

Perhaps a develop branch or so makes sense. From main the releases are build and every release should include all the necessary bindings. But in develop languages are allowed to diverge from each other. On a regular basis and if develop is mature enough it is merged into main, often hopefully.

Or bindings are developed in other repos?

[mparno]

I doubt that c++ will be the primary language that MParT is used from. My guess is python will be the most used, followed by Julia, matlab, and lastly c++.

Perhaps a develop branch or so makes sense.

This is tempting, but I'm hesitant to incorporate too many steps before something get's merged into main. We've tried various things with MUQ in the past and it became cumbersome to have both a develop branch and a main branch. An alternative could be to use tags in the main branch. The main branch will constantly be updated but we can have certain criteria for a "release", such as making sure the bindings are up to date with the c++ code, and can tag a specific commit in the main branch a version number (e.g., v0.1.0) to tag it as a "release". If someone wants to use the latest c++ improvements, they can still just pull from the latest commit to main, but they can also be sure that the most recent release will have more complete bindings. Would that work for everyone?

[rubiop]

I agree with the usage ranking, your tag idea seems good to me. I think it is worth trying it and see how it goes!