Looking for (co-)maintainers

[awvwgk]

I'm looking for somebody interested in developing and maintaining this project going forward.

Personally, I consider this project finished given the initial scope was to provide native integration with QCEngine and ASE for the xTB methods, therefore I'm not planning to add new features, which doesn't mean this project is not going to accept any feature additions.

Current scope

The project mainly deals with Python/C interop for the C-API exposed in xtb (see src/api in the xtb repository) and development is therefore tied tightly to the xtb C bindings. There might be an argument to drop this project in favor of the tblite library in the future or use tblite directly to provide the functionality exposed here. The overall design principle of the C and Python bindings are described in this presentation for the ESL Fortran OOP seminar series.

Project assets

• conda-forge feedstock: https://github.com/conda-forge/xtb-python-feedstock
• readthedocs pages: https://xtb-python.readthedocs.io

[TyBalduf]

Would this also entail co-maintaining xTB itself, since new developments would be highly dependent on what features are available in xTB and how they are exposed through the C-api?

[awvwgk]

This repository is closely tied to xtb, (co-)maintaining xtb-python is likely to involve active contributions to the xtb C API and maybe other parts of the main code base. It kind of makes sense for the xtb-python maintainers to own the C API of xtb.

[awvwgk]

@TyBalduf I invited you as maintainer for this project, see https://github.com/grimme-lab/xtb-python/invitations. Let me know if there is anything I can help with.

[coltonbh]

@awvwgk I plan to use xtb quite a bit over the coming months and may be up for helping do some maintenance. Initially I could offer some basic devops stuff, e.g., basic toolchain work with ruff, isort, black, mypy, GitHub actions and auto-deployment workflows to clean up the project and help make the repo more auto-maintaining. I can also help with packaging. Longer term could potentially contribute to xtb more directly.

Similar to what @TyBalduf asked, I'm first curious to know more about the current structure of the xtb development landscape. There's the original xtb Fortran package, the newer tblite (which claims to contain core code for both xtb and dftb+, though I can't if it's actually used this way and it already has its own python API), CREST which in the latest paper claims to have re-implemented xtb functionality itself for better performance, and this xtb-python package. There's xtbs everywhere 😂!

So we have:

• xtb written in Fortran
• tblite written in Fortran with some sort of python wrapper included
• python-xtb This project! Which appears to be a wrapper around xtb and is now claimed to no longer be under active development.
• CREST which claims to have reimplemented xtb functionality and makes heavy use of xtb for metadynamics.

What is the relationship between these four projects? Does one contain the core xtb routines and the others (like CREST) build higher level abstractions on top of it? Are they all developed by the same team/lab? tblite and CREST are not under the grimme-lab--are they separate projects? What's the difference between tblite and xtb? I.e., if tblite contains the core xtb Hamiltonian implementation, what does the xtb package add on top of it? And if we use tblite what xtb functionality are we missing out on? Does it make more sense to have a python API on top of xtb so that we can access the full suite of xtb features instead of just those in tblite?

What I care about is having a high performance, stable, interface to xtb routines via python and I'm willing to contribute to help make that happen :)

Fill me in on the development landscape and perhaps there's a place I can help out 💪

[awvwgk]

The xtb-python package is my first attempt to export the xTB methods to Python. I learned a few lessons here, first having Python bindings separated from the main project becomes quite painful to maintain choosing a different versioning scheme didn't help, second Python bindings which target only a subset of features like energy calculations suffer a bit if they require a huge library with lots of other unused features, third exporting features from the library which were not developed with API usage in mind requires significant changes in the upstream library.

Overall these suboptimal design choices for xtb-python made me reconsider my approach and I started tblite, which implements the xTB methods with an API first approach to provide a modular framework for using xTB in different situations. This is indeed quite successful as xtb is moving towards having tblite's Fortran API as sole implementation of the xTB methods. Similarly, crest switched to tblite's Fortran API to replace the xtb CLI wrapper used before, this required to reimplement features of xtb in crest but overall provided a more robust framework. Finally, tblite comes with its own Python API which is meant as replacement for xtb-python.

Hope this gives some clarity why xtb-python is not maintained anymore and we are moving towards tblite as an alternative.

[coltonbh]

Amazing! Thank you! Are you looking for maintainers for tblite then? I could potentially help out with packaging (move towards a pyproject.toml file with PEP 517 compliance) and an automated system for building, packaging, and distributing (via PyPI).

Are there other specific contributions you would find helpful?

[awvwgk]

Help is always welcome, tblite is a volunteer project and I am mostly working on it in my spare time if there is any.

[coltonbh]

Got it. I'd like to be able to pip install tblite into other projects and have it "just work" (i.e., build/compile the requisite codes for Fortran (or have pre-built binaries shipped to PyPI) with no additional effort required). Ideally, we'd have an automated build/deploy process from GitHub actions to PyPI (akin to this, code here) so that bugfixes can be quickly released to production.

I can't tell from your documentation on PyPI but does pip install tblite "just work" or do you have to do builds against some local version of tblite that you've already compiled? What's missing (if anything) to get to what I'm proposing above? I'd be happy to contribute to help get there :)

[awvwgk]

At the moment tblite has wheels for Linux only, contributions for getting wheels on other platforms are welcome.

[coltonbh]

Great. Can't do anything immediately, but am up for making contributions as I run into speed bumps for some of the applications I have in mind. Thanks for filling me in on the state of the project :)