Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

prevent pip dependency retrieval, rely on rosdep instead. #199

Open
asmodehn opened this issue Apr 21, 2018 · 0 comments
Open

prevent pip dependency retrieval, rely on rosdep instead. #199

asmodehn opened this issue Apr 21, 2018 · 0 comments

Comments

@asmodehn
Copy link
Member

We tend to not have tests in installed packages anymore, to reduce maintenance costs... debatable but that is the usual de facto practice currently.

So we need to make sure the dependencies in devel workflow (where we test) are the same as the final environment where the package will be installed.

However one of the main point of catkin_pip in a devel workspace, is to retrieve all recent versions from PyPI to make sure everything works together.

Previously, we use to run tests again in the install workspace with ros dependencies to find out any potential problems there. However this is not really doable in practice, which means that in the devel space, we need a way to skip the installation of python dependencies to rely on installed ROS packages OR to pin dependencies version to the same version as the ROS package.

Note that pinning to ROS version is already the preferred approach in Python packages when testing for a specific ROS distro.

So in the actual ROS package release process, we should use an option that uses dependencies from rosdep, and does not retrieve dependencies with pip. This would be somewhat of a special case for an automated ROS build test, as it is useful to get pip dependencies during development.

Such a feature needs to be identified and if needed, implemented in catkin_pip.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant