Preinstall AWB in lab image#483
Conversation
68f6607 to
bb076af
Compare
7c3e9e6 to
fc310bb
Compare
4a169a4 to
2682d6e
Compare
|
For some reason ASE on conda-forge depends on flask, which bring in a ton of other dependencies. I opened a PR on the ASE feedstock to remove it |
b3a34e9 to
1f243e1
Compare
|
Faling tests are because of
Looks like bad metadata of |
5a7e94e to
bf4bc74
Compare
There was a problem hiding this comment.
LGTM! Thanks @danielhollas. When you say "the big disadvantage is the size of the image" - how big?
|
Thanks @edan-bainglass (this is staged on top of #479 so not merging yet). Also would like to get green light from @yakutovicha |
The goal here is to pre-install AWB into the image from a conda package to:
~/.localatomic_toolsextras from aiida-core which share a lot of the packages with AWB (e.g. ase) and so it is generally good to ensure that the supported versions are compatible with each other. Also,atomic_toolsincludes pymatgen and scipy, which we had issues with installing from PyPI before (see scipy from conda, for correct BLAS/LAPACK operations in arm64 #526)Obviously, the big disadvantage is the size of the image, but to me the increase stability seems worth it. Also, applications dependending on AWB (like QeApp) would end up installing the packages anyways, and installing them from conda is actually generally more efficient since conda packages do not vendor non-python code).
NOTE: We cannot pin the exact AWB version, because apps need to be able to upgrade or even downgrade the pre-installed version according to their needs. But the thesis is that most of the AWB dependencies are not changed in between AWB versions and so it still makes sense to have them pre-installed. We probably can specify the lowest supported AWB version (which since this is build on the python 3.12 image will be AWB 3.0)
Staged on top of #455
Closes #526