AtomsIO.jl icon indicating copy to clipboard operation
AtomsIO.jl copied to clipboard

Update package to use package extensions

Open thazhemadam opened this issue 2 years ago • 1 comments

Update the package to use package extensions, instead of explicitly depending on all the respective packages it supports. The package still at a high level remains the same interface wise and this makes it a lot lighter.

thazhemadam avatar Nov 03 '23 11:11 thazhemadam

Thanks for the PR. The first fix (for the tests) I would take immediately.

For the second aspect (splitting into extensions). I'm not sure I agree. Do you have a use case in mind that requires you to do this or where you have great disadvantages without using package extensions ?

The original rational to not use package extensions is:

  • To me AtomsIO is a "user-facing package", i.e. a package mostly meant for interactive explorations and small scripts and not for speed, so the compromise is overall more towards convenience rather than being lightweight. If you want a lightweight way of loading files, you could use the dependent packages directly, which by now all support AtomsBase in some form or another. In case there is a need for a common interface that is as lightweight as possible, we can think about how to get there, but this is tricky with package extensions also for other reasons ...
  • Some formats are supported by multiple packages, but since formats are underspecified not all packages support everything and moreover as a result of the underspecification writing format A with Package X and reading it with Package Y can lead to issues. In AtomsIO we ensure that the same packages are always tried in the same order, such that you are guaranteed that a save_system to format A followed by a load_system from format A is as lossless as possible. With using package extensions the behaviour of load_system / save_system depends on what packages are loaded, which can lead to subtle inconsistencies in the data or the simulation, which in my opinion should be avoided as much as possible.
  • Keeping an explicit overview over the packages that exist for parsing files and which respective file formats they support is tedious. With package extensions I would need to keep track of this and do an explicit using PkgX matching the file type I have at hand. Having AtomsIO depend explicitly, it is a superpackage which just tries all possible packages, without me having to worry.

mfherbst avatar Nov 08 '23 08:11 mfherbst