Open awvwgk opened 2 years ago
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?
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
.
@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.
@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 xtb
s everywhere :joy:!
So we have:
xtb
and is now claimed to no longer be under active development.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 :muscle:
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.
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?
Help is always welcome, tblite is a volunteer project and I am mostly working on it in my spare time if there is any.
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 :)
At the moment tblite has wheels for Linux only, contributions for getting wheels on other platforms are welcome.
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 :)
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
(seesrc/api
in thextb
repository) and development is therefore tied tightly to thextb
C bindings. There might be an argument to drop this project in favor of thetblite
library in the future or usetblite
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