You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Motivation for making the issue/discussion: There was a suggestion to use some kind of centralised resource management abstraction via ResourceResolvers from pyiron_snippets.
We need to decide how configs for resource paths and the like should work in pyiron_workflow node libraries... I would strongly prefer a per-software configuration in each node-module instead of centralised configuration inheritance. Most users only use 2-3 different types of software. This (to me) doesn't justify abstraction complexity to minimise code duplication.
Furthermore, there's lots of ways different software works. E.g. some software requires proprietary licenses, placed on different places, with other resources elsewhere. You can't just place these in a "pyiron_resources" folder.
I make this comment because while attempting to minimise code duplication is tempting via abstractions, consider:
# Initialize the resource resolverresource_paths= [str(Path.home().joinpath("pyiron-resources-cmmc"))]
module="vasp"subdirs= ["potentials"]
resolver=ResourceResolver(resource_paths, module, *subdirs)
# Define the file pattern to search forsearch_patterns= ["potentials_vasp.csv"]
# Perform the searchpotcar_df=pd.read_csv(resolver.first(search_patterns))
The config file probably looks extremely different for different types of code (plugins for abacus/ansys, potentials for lammps, etc.).
ResourceResolver doesn't solve anything in this case, and obfuscates, minimises readability by a lot.
I guess my point is that it is far simpler to let users generate their software-specific configuration files. A centralised abstraction does not make sense here. After all, the users of the software know best how they would prefer software specific resources set up. If we use centralised resource configuration, the pyiron_nodes risk running into the same problem (in my view) experienced by many external users wrt. normal pyiron; expectation of conformity to how we expect people to do things (e.g. job run cycle etc.) vs. the many different ways everyone else does things.
The text was updated successfully, but these errors were encountered:
Motivation for making the issue/discussion: There was a suggestion to use some kind of centralised resource management abstraction via ResourceResolvers from pyiron_snippets.
We need to decide how configs for resource paths and the like should work in pyiron_workflow node libraries... I would strongly prefer a per-software configuration in each node-module instead of centralised configuration inheritance. Most users only use 2-3 different types of software. This (to me) doesn't justify abstraction complexity to minimise code duplication.
Furthermore, there's lots of ways different software works. E.g. some software requires proprietary licenses, placed on different places, with other resources elsewhere. You can't just place these in a "pyiron_resources" folder.
I make this comment because while attempting to minimise code duplication is tempting via abstractions, consider:
versus:
The config file probably looks extremely different for different types of code (plugins for abacus/ansys, potentials for lammps, etc.).
ResourceResolver doesn't solve anything in this case, and obfuscates, minimises readability by a lot.
I guess my point is that it is far simpler to let users generate their software-specific configuration files. A centralised abstraction does not make sense here. After all, the users of the software know best how they would prefer software specific resources set up. If we use centralised resource configuration, the pyiron_nodes risk running into the same problem (in my view) experienced by many external users wrt. normal pyiron; expectation of conformity to how we expect people to do things (e.g. job run cycle etc.) vs. the many different ways everyone else does things.
The text was updated successfully, but these errors were encountered: