Use Structuretoolkit

[jan-janssen]

https://github.com/pyiron/structuretoolkit

[jan-janssen]

This pull request is part of the greater effort to separate pyiron into more stand-alone packages. This change gives users the chance to benefit from pyiron without having to switch their whole workflow to pyiron. In this specific case, new users can benefit from our neighbor analysis and general analysis for atomistic structures, by combining the structuretoolkit with ASE atomistic structures. The hope is that when users enjoy the software developed by the pyiron developers then they are hopefully also interested to use the pyiron project as a whole. Now this pull request removes the code which is now included in the structuretoolkit and just imports the corresponding functionality.

[samwaseda]

Sorry I missed this review request (I’m also on vacation right now). But this import statement currently breaks my notebooks. Is it my problem (which obviously I can fix by cloning the repository), or is it more a major problem?

[jan-janssen]

You can install structuretoolkit via conda that should fix the import issue, at least the tests all pass.

[samwaseda]

It doesn’t sound like a solution for pyiron

[jan-janssen]

It doesn’t sound like a solution for pyiron

It is part of the dependencies so for regular users it is installed automatically. Only developers have to manually install the dependencies.

[samwaseda]

But I still don’t understand why it’s not automatically installed on my side when I install pyiron. It’s not released yet as an official pyiron version?

[jan-janssen]

No, the changes were merged three days ago and there was no release of a new official pyiron version since then. It is going to be included with the next official release.

[samwaseda]

It actually makes me feel that this splitting would create only discrepancies. Is there a particular reason that it should be a separate package?

[jan-janssen]

It actually makes me feel that this splitting would create only discrepancies. Is there a particular reason that it should be a separate package?

The original discussion was in https://github.com/pyiron/team/discussions/162 . The split is essential part of the strategy to make parts of pyiron accessible to a larger audience without forcing them to us pyiron as a whole. The structuretoolkit is fully compatible to the ASE atoms class which also helps us to focus on the migration away from the pyiron atoms class towards the ASE atoms class. In the mid-term the goal is to have the job management on top of the structuretoolkit and individual wrappers like pyiron_lammps, similar to the way how dask is used on top of python, rather than requiring each python class to be derived from a dask class.

[samwaseda]

Ok that’s more or less the argument that I had expected. I don’t oppose it, but I also have the feeling that we don’t have a clear picture of how pyiron_atomistics should be split, or it hasn’t really been talked through. And at the pyiron meeting you presented pyiron_lammps and structuretoolkit as experimental features, so I’m now a bit confused that it is now included in the official pyiron version.

But ok anyway let’s keep it like this.