pyiron_workflow depends on pyiron_atomistics and pyiron_base leading to a large number of dependencies

[srmnitc]

Summary

pyiron_workflow depends on pyiron_atomistics and pyiron_base, which in turn depends on a large number of packages. This makes the workflow package rather heavy for a user who might want to use it solely to leverage the power of workflows. Would it make sense to release the dependencies and make this package rather light weight?

[liamhuber]

Absolutely. There's a clear path for this too, it just hasn't been high priority.

Our dependency on pyiron_base is currently just logger and Singleton. These could be git-copied over here, or (better IMO) we can start a new repo of standard-libarary-only-depenency pyiron tools as discussed in this issue over on base.

Our dependency on pyiron_atomistics is only for actual individual nodes, and not in the infrastructure. At the latest when the node_library submodule gets pulled out/broken apart into node library module(s), we'll lose this dependency. We can probably make it optional even before then by moving the import inside the individual node functionalities.

[liamhuber]

This was resolved and both those packages are out of the dependency stack, buuuut, I'm probably about to add base back in in order to get storage rolling, so I'll leave this open.

[liamhuber]

This was resolved and both those packages are out of the dependency stack, buuuut, I'm probably about to add base back in in order to get storage rolling, so I'll leave this open.

Nope, we'll just move tinybase here, per #161. So this is out, the dependency is strictly for the node libraries that depend on those modules.

[liamhuber]

#160 introduces pyiron_contrib dependency, although it's not planned to stay this way. I'm re-opening to keep track of the shortcoming.

[liamhuber]

I'm also slapping on boto3 as long as contrib is not playing nice