Provide a shortcut to ase.build

[liamhuber]

So that we can do common stk operations using a single import. Tests and readme are updated accordingly.

structuretoolkit.build.ase is ase.build
>>> True

[jan-janssen]

@liamhuber Can you extend the test a bit, to test the typical functionality of the ase.build module? My fear is that ASE might change their functionality at some point and we only notice it by users complaining. For the same reason I added tests for the most commonly used functions from pyscal in https://github.com/pyiron/structuretoolkit/blob/main/tests/test_pyscal.py

[liamhuber]

@liamhuber Can you extend the test a bit, to test the typical functionality of the ase.build module?

I don't think we should do this. Right now the promise in the documentation, the implementation in the code, and the test are all in full alignment: we are simply providing a shortcut to another module, structuretoolkit.build.ase is ase.build.

My fear is that ASE might change their functionality at some point and we only notice it by users complaining.

Before this change, users had to keep their ase.build calls up-to-date with ase; after this changes users need to keep their ase.build calls (via stk.build.ase) up-to-date with ase. No changes here. If they complain all we need to do is let them know ase has updated and the rest is on them; if they want to downgrade their version of ase to keep their existing code working there's nothing that stops them -- all this does is link to the ase library.

For the same reason I added tests for the most commonly used functions from pyscal in https://github.com/pyiron/structuretoolkit/blob/main/tests/test_pyscal.py

First, I see this as a fundamentally different case. These tests check the behaviour of the public-facing methods stk.common.ase_to_pyscal, stk.analyse.get_steinhardt_parameters, stk.analyse.get_centro_symmetry_descriptors, stk.analyse.get_adaptive_cna_descriptors, get_diamond_structure_descriptors and stk.analyse.get_voronoi_volumes (btw I see now stk.analyse.find_solids is missing!), all of which are functions with actual bodies that we implement in str.common and stk.analyse.pyscal. Therefore it's right and good that we test them.
In contrast, stk.build.ase has zero content from our end. Any tests would just be some sort of duplication of ase tests and are unnecessary. We have no interface or promises to maintain other than that we are giving access to ase, which is what's tested.

Second, I think it would offer very little benefit. If we are testing just "common" cases (e.g. ase.build.bulk), then we're going to see tests fail elsewhere anyhow, since we use ase.build everywhere anyway! So testing standard calls would just be dead weight.

So, I am very much against expanding the tests beyond this -- BUT, I think it's perfectly fair to ask whether we want to provide a shortcut at all! The "pro" is that we can have a single point of import for a bunch of examples/tests/etc., which is great for lazy people like me. The "cons" are that we may come across as "stealing" ase functionality (I think this is not too bad since we explicitly call it build.ase) and your fear that users may mistakenly think we're the ones responsible for ase.build staying backwards-compatible.

I wanted to get your eyes on this in case you felt we should reject the idea in its entirety. I'm in favour of merging it (obviously), but I would accept your veto with zero hurt feelings.