Consider re-integrating PyARPES
- Dominant language
- Python
- Stars
- 19
- Forks
- 8
- Avg merge
- 6h 39m
- Merged PRs (30d)
- 44
Description
PyARPES seems to be unmaintained: https://github.com/chstan/arpes/issues/23
But has a maintained fork! https://github.com/chstan/arpes/issues/23#issuecomment-2056771585
Although we moved away from PyARPES functionality and are happy, maybe we could consider re-adding compatibility layers since they have many more data plugins...
Options:
- Discard our data model, roll back to PyARPES conventions
* Pros: we get access to data loaded by PyARPES data loaders!
* Cons: I personally dislike a lot of things about their data convention like angle notation and attribute mangling, our momentum conversion will need major fixes
- Write a conversion function that transforms PyARPES data format to match ours
* This should be easy since PyARPES format is very constrained
* However the other way around will be quite hard
* And duplicated loader functionality is chaos
- Write a compatibility layer that subclasses a PyARPES loader and BaseLoader (multiple inheritance)
* Use PyARPES loaders with our syntax!
* Is this even possible?
- Ignore PyARPES and move on
* The easiest way
* However majority of attempts to analyze ARPES data with python are concentrated in PyARPES, could it become standard in the future?
* We have to implement more data loaders for this to not be a problem
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.