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
This should be fixed in aiida and aiidalab roles then uncommented.
Holistically, it would perhaps be ideal to have a better solution for installing packages into the virtualenv.
Creating a virtualenv in a single step, e.g. with pip install -r requirements.txt, is usually fine; correctly solving compatible dependencies or failing if it can't resolve.
The problem comes when you start having subsequent installs (pip install apackage), which pip seems to allow clobbering existing dependency requirements, which only shows up when you subsequently run pip check.
Currently, the process is to:
Create the virtualenv
Install aiidalab + deps
Install aiida-core + deps
Iteratively install each aiida plugin + deps
the other issue is also that, e.g. if the aiidalab role installs (and is tested against) aiida-core v1.3.0, then the aiida role "overwrites" this install with aiida-core v1.4.2.
At the moment you just have to be manually careful to add compatible aiida and aiidalab role versions.
even if the aiida and aiidlab roles pass their testing independently, this does not necessarily ensure that there will not be issues introduced in the full build.
Perhaps the pip 2020 resolver will improve this issue?
(also conda tends to handle this a lot better, but that would be a big effort to start including conda in the VM)
with quantum mobile, we in essence have two competing goals:
in one sense it is a tool for building VMs, in which case we want the user to have the flexibility to create a custom build to their own specification (with particular codes/plugins etc).
In this case we probably don't want to constrain them to a fixed lock file
On the other hand we offer the "pre-made" VM releases which are more like a service and the environment should be fully "validated". In which case a lock file may be better
For aiidalab, it is currently very focussed on the latter and "hard-codes" the whole environment, encapsulated in a docker image with a set version for the whole image (this version incorporates not just the python versions, but also the DFT code versions and other software like postres and rabbitmq)
For quantum-mobile we need to consider what the balance is
Currently, the pip check is commented out, because it fails:
quantum-mobile/playbook-build.yml
Lines 123 to 132 in b2632be
This should be fixed in aiida and aiidalab roles then uncommented.
Holistically, it would perhaps be ideal to have a better solution for installing packages into the virtualenv.
Creating a virtualenv in a single step, e.g. with
pip install -r requirements.txt
, is usually fine; correctly solving compatible dependencies or failing if it can't resolve.The problem comes when you start having subsequent installs (
pip install apackage
), which pip seems to allow clobbering existing dependency requirements, which only shows up when you subsequently runpip check
.Currently, the process is to:
the other issue is also that, e.g. if the aiidalab role installs (and is tested against) aiida-core v1.3.0, then the aiida role "overwrites" this install with aiida-core v1.4.2.
At the moment you just have to be manually careful to add compatible aiida and aiidalab role versions.
even if the aiida and aiidlab roles pass their testing independently, this does not necessarily ensure that there will not be issues introduced in the full build.
Perhaps the pip 2020 resolver will improve this issue?
(also conda tends to handle this a lot better, but that would be a big effort to start including conda in the VM)
cc @ltalirz and @csadorf
The text was updated successfully, but these errors were encountered: