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
The current dependencies listed in environment.yml for OpenFold use strict version constraints (e.g., package==version). While this approach helps maintain compatibility, it can create challenges, especially for developers looking to integrate OpenFold into their own projects.
The issue is particularly relevant as many dependencies, including Python and key Biopython packages, evolve rapidly. These strict version requirements can make it harder to incorporate OpenFold alongside other tools or within environments that need more flexibility.
Would it be possible to relax some of these version constraints? Perhaps using package > version or package ~= version could strike a better balance between compatibility and flexibility.
The text was updated successfully, but these errors were encountered:
The most prominent issue is with pytorch::pytorch==1.12.*, which is both strict and outdated. This causes problems because the underlying CUDA version is quite restricted, as PyTorch doesn’t always compile against all CUDA versions. Since the conda-forge channel tends to update cudatoolkit versions quickly, this creates dependency problems.
In terms of a quick fix, I’m thinking of adding the nvidia channel to the environment.yml as a source, which could provide better flexibility for handling newer CUDA versions. Also a cuda-nvcc dependency is needed to build the pip dependencies. Would this be a reasonable solution?
The current dependencies listed in environment.yml for OpenFold use strict version constraints (e.g.,
package==version
). While this approach helps maintain compatibility, it can create challenges, especially for developers looking to integrate OpenFold into their own projects.The issue is particularly relevant as many dependencies, including Python and key Biopython packages, evolve rapidly. These strict version requirements can make it harder to incorporate OpenFold alongside other tools or within environments that need more flexibility.
Would it be possible to relax some of these version constraints? Perhaps using
package > version
orpackage ~= version
could strike a better balance between compatibility and flexibility.The text was updated successfully, but these errors were encountered: