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
In the next release, we should aim to make our requirements for core dependencies a bit more permissive so that we don't have to uninstall stuff in Google Colab (and to make it easier to install SLEAP in mixed use envs in general).
numpy which right now is upper bounded at 1.21.5, but Colab is currently on 1.21.6. Separately, I've also had issues with installing on different environments that seem to prefer pulling in 1.21.6 -- maybe this might be from another dependency we have?
attrs which we pin exactly to 21.2.0, but Colab is currently on 21.4.0. This might be related to compatibility with cattrs which we have pinned to 1.1.1. Newer versions break a lot of our serialization/deserialization since they changed the way they do class resolution during structuring, so we'd need to fix a bunch of those issues before we can upgrade (unless attrs==21.4.0 still works with cattrs==1.1.1).
tensorflow is actually pretty permissive right now -- we allow tensorflow>=2.6.3,<2.9.0 which includes the Colab default of 2.8.2. The only thing to consider is whether to update the default in the conda package from 2.6.3 to something newer. This was blocked by TensorFlow 2.7 does not detect CUDA installed through conda tensorflow/tensorflow#52988 since TF>2.7 doesn't seem to play nicely with detecting the conda cudatoolkit binaries. FWIW, the conda-forge distribution of tensorflow is looking pretty good, so we might want to replace our janky one with that one which has better support across OSes (and might have resolved the binary detection issue).
With all of these updates, the easy first pass thing is to just see if we can expand the upper bound on all of these packages so that for pip-based installations (like in Colab) we won't have any conflicts.
After that, we need to consider whether to update the defaults in the conda package and check everything across OSes.
In the next release, we should aim to make our requirements for core dependencies a bit more permissive so that we don't have to uninstall stuff in Google Colab (and to make it easier to install SLEAP in mixed use envs in general).
The important deps to consider are:
opencv-python
/opencv-python-headless
: It might be worthwhile switching toopencv-python
entirely, or at least until we fix Switch to albumentations for augmentation #648, so we don't risk having double installs or running into issues like Unable to import video into project #830. Colab is currently onopencv-python==4.6.0
(not headless).numpy
which right now is upper bounded at1.21.5
, but Colab is currently on1.21.6
. Separately, I've also had issues with installing on different environments that seem to prefer pulling in1.21.6
-- maybe this might be from another dependency we have?attrs
which we pin exactly to21.2.0
, but Colab is currently on21.4.0
. This might be related to compatibility withcattrs
which we have pinned to1.1.1
. Newer versions break a lot of our serialization/deserialization since they changed the way they do class resolution during structuring, so we'd need to fix a bunch of those issues before we can upgrade (unlessattrs==21.4.0
still works withcattrs==1.1.1
).tensorflow
is actually pretty permissive right now -- we allowtensorflow>=2.6.3,<2.9.0
which includes the Colab default of2.8.2
. The only thing to consider is whether to update the default in the conda package from 2.6.3 to something newer. This was blocked by TensorFlow 2.7 does not detect CUDA installed through conda tensorflow/tensorflow#52988 since TF>2.7 doesn't seem to play nicely with detecting the condacudatoolkit
binaries. FWIW, the conda-forge distribution of tensorflow is looking pretty good, so we might want to replace our janky one with that one which has better support across OSes (and might have resolved the binary detection issue).With all of these updates, the easy first pass thing is to just see if we can expand the upper bound on all of these packages so that for
pip
-based installations (like in Colab) we won't have any conflicts.After that, we need to consider whether to update the defaults in the conda package and check everything across OSes.
Packages on Colab (as of July 27, 2022)
The text was updated successfully, but these errors were encountered: