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
Early detect when a package provided by the robotology-superbuild installed with conda dependencies is also present in the conda environment itself
#1779
Open
traversaro opened this issue
Dec 21, 2024
· 0 comments
As the conda binaries for projects built by the robotology-superuild see an increase of usage (for example yarp, idyntree or casadi) it happens more and more that the users experience problems as they try to build the robotology-superbuild in an environment in which some package built by the robotology-superbuild is already present. What is particularly tricky is that users sometimes did not installed the package explicitly, but it was installed as a transitive dependencies.
In this issue I would like to discuss how to mitigate this problem. For example, we could have a check in the robotology-superbuild that lists the conda packages present in the environment, and check for conflicts to either raise an error or a visible warning (probably an error may be the only way for users to actually check it out, but I am a bit afraid it may be more harmful then beneficial).
The text was updated successfully, but these errors were encountered:
As the conda binaries for projects built by the robotology-superuild see an increase of usage (for example yarp, idyntree or casadi) it happens more and more that the users experience problems as they try to build the robotology-superbuild in an environment in which some package built by the robotology-superbuild is already present. What is particularly tricky is that users sometimes did not installed the package explicitly, but it was installed as a transitive dependencies.
In this issue I would like to discuss how to mitigate this problem. For example, we could have a check in the robotology-superbuild that lists the conda packages present in the environment, and check for conflicts to either raise an error or a visible warning (probably an error may be the only way for users to actually check it out, but I am a bit afraid it may be more harmful then beneficial).
The text was updated successfully, but these errors were encountered: