Revision history [back]

It's probably possible, but seems a bit unnecessary.

ROS has various tools for managing source checkouts, such as vcstool, wstool and rosinstall_generator.

For binary management and installation -- of both ROS package dependencies as well as system dependencies -- rosdep is used.

Setting up a source workspace from a given my_awesome_ros_application.rosinstall (which only contains references to source repositories of your own packages or forks of upstream packages) file is a matter of:

$ source /opt/ros/$distro/setup.bash
$ mkdir $HOME/catkin_ws && cd $HOME/catkin_ws
$ sudo rosdep init && rosdep update
$ wstool init -j8 $HOME/catkin_ws/src http://location/of/your/my_awesome_ros_application.rosinstall
$ rosdep install -y --from-paths $HOME/catkin_ws/src --ignore-src -y

At this point you'll have your entire system setup to start developing on the packages.

It's probably possible, but seems a bit unnecessary.

ROS has various tools for managing source checkouts, such as vcstool, wstool and rosinstall_generator.

For binary management and installation -- of both ROS package dependencies as well as system dependencies -- rosdep is used.

Setting up a source workspace from a given my_awesome_ros_application.rosinstall (which only contains references to source repositories of your own packages or forks of upstream packages) file is a matter of:

$ source /opt/ros/$distro/setup.bash
$ mkdir $HOME/catkin_ws && cd $HOME/catkin_ws
$ sudo rosdep init && rosdep update
$ wstool init -j8 $HOME/catkin_ws/src http://location/of/your/my_awesome_ros_application.rosinstall
$ rosdep install -y --from-paths $HOME/catkin_ws/src --ignore-src -y

At this point you'll have your entire system setup to start developing on the packages.

It's probably possible, but seems a bit unnecessary.

ROS has various tools for managing source checkouts, such as vcstool, wstool and rosinstall_generator.

For binary management and installation -- of both ROS package dependencies as well as system dependencies -- rosdep is used.

Setting up a source workspace from a given my_awesome_ros_application.rosinstall file (which only contains references to source repositories of your own packages or forks of upstream packages) file is a matter of:

$ source /opt/ros/$distro/setup.bash
$ mkdir $HOME/catkin_ws && cd $HOME/catkin_ws
$ sudo rosdep init && rosdep update
$ wstool init -j8 $HOME/catkin_ws/src http://location/of/your/my_awesome_ros_application.rosinstall
$ rosdep install -y --from-paths $HOME/catkin_ws/src --ignore-src -y

At this point you'll have your entire system setup to start developing on the packages.

My suggestion would be to store only the source repositories of your own packages, and deploy dependencies from the binary repositories as much as possible. Using released binaries is preferably in any case, unless:

1. there are no binaries available (because the pkg has not been released, in general, for your platform / cpu arch, or a particular version is no longer / not yet available)
2. you need a source checkout as you want to work on the actual pkg itself
3. you deploy to systems that absolutely cannot use released binaries
4. you must absolutely guarantee reproducable builds and need a source snapshot of all your dependencies (and their dependencies, etc)

It's probably possible, but seems a bit unnecessary.

ROS has various tools for managing source checkouts, such as vcstool, wstool and rosinstall_generator.

For binary management and installation -- of both ROS package dependencies as well as system dependencies -- rosdep is used.

Setting up a source workspace from a given my_awesome_ros_application.rosinstall file (which only contains references to source repositories of your own packages or forks of upstream packages) is a matter of:

$ source /opt/ros/$distro/setup.bash
$ mkdir $HOME/catkin_ws && cd $HOME/catkin_ws
# init only needed once, update regularly
$ sudo rosdep init && rosdep update
$ source /opt/ros/$distro/setup.bash

# create and populate workspace (done once)
$ mkdir $HOME/catkin_ws && cd $HOME/catkin_ws
$ wstool init -j8 $HOME/catkin_ws/src http://location/of/your/my_awesome_ros_application.rosinstall
$ rosdep install -y --from-paths $HOME/catkin_ws/src --ignore-src -y

At this point you'll have your entire system setup to start developing on the packages.packages. Change management can be done per repo, or when using vcstool per workspace.

My suggestion would be to store only the source repositories of your own packages, packages (not the entire catkin_ws), and deploy dependencies from the binary repositories as much as possible. Using released binaries is preferably in any case, unless:

1. there are no binaries available (because the pkg has not been released, in general, for your platform / cpu arch, or a particular version is no longer / not yet available)
2. you need a source checkout as you want to work on the actual pkg itself
3. you deploy to systems that absolutely cannot use released binaries
4. you must absolutely guarantee reproducable builds and need a source snapshot of all your dependencies (and their dependencies, etc)

It's probably possible, but seems a bit unnecessary.

ROS has various tools for managing source checkouts, such as vcstool, wstool and rosinstall_generator.

For binary management and installation -- of both ROS package dependencies as well as system dependencies -- rosdep is used.used (#q215059).

Setting up a source workspace from a given my_awesome_ros_application.rosinstall file (which only contains references to source repositories of your own packages or forks of upstream packages) is a matter of:

# init only needed once, update regularly
$ sudo rosdep init && rosdep update
$ source /opt/ros/$distro/setup.bash

# create and populate workspace (done once)
$ mkdir $HOME/catkin_ws && cd $HOME/catkin_ws
$ wstool init -j8 $HOME/catkin_ws/src http://location/of/your/my_awesome_ros_application.rosinstall
$ rosdep install -y --from-paths $HOME/catkin_ws/src --ignore-src -y

At this point you'll have your entire system setup to start developing on the packages. Change management can be done per repo, or when using vcstool per workspace.

My suggestion would be to store only the source repositories of your own packages (not the entire catkin_ws, #q264600), and deploy dependencies from the binary repositories as much as possible. Using released binaries is preferably in any case, unless:

1. there are no binaries available (because the pkg has not been released, in general, for your platform / cpu arch, or a particular version is no longer / not yet available)
2. you need a source checkout as you want to work on the actual pkg itself
3. you deploy to systems that absolutely cannot use released binaries
4. you must absolutely guarantee reproducable builds and need a source snapshot of all your dependencies (and their dependencies, etc)

It's probably possible, but seems a bit unnecessary.unnecessary (and somewhat infeasible: how are you going to manage tracking upstream?).

ROS has various tools for managing source checkouts, such as vcstool, wstool and rosinstall_generator.

For binary management and installation -- of both ROS package dependencies as well as system dependencies -- rosdep is used (#q215059).

Setting up a source workspace from a given my_awesome_ros_application.rosinstall file (which only contains references to source repositories of your own packages or forks of upstream packages) is a matter of:

# init only needed once, update regularly
$ sudo rosdep init && rosdep update
$ source /opt/ros/$distro/setup.bash

# create and populate workspace (done once)
$ mkdir $HOME/catkin_ws && cd $HOME/catkin_ws
$ wstool init -j8 $HOME/catkin_ws/src http://location/of/your/my_awesome_ros_application.rosinstall
$ rosdep install -y --from-paths $HOME/catkin_ws/src --ignore-src -y

At this point you'll have your entire system setup to start developing on the packages. Change management can be done per repo, or when using vcstool per workspace.

My suggestion would be to store only the source repositories of your own packages (not the entire catkin_ws, #q264600), and deploy dependencies from the binary repositories as much as possible. Using released binaries is preferably in any case, unless:

1. there are no binaries available (because the pkg has not been released, in general, for your platform / cpu arch, or a particular version is no longer / not yet available)
2. you need a source checkout as you want to work on the actual pkg itself
3. you deploy to systems that absolutely cannot use released binaries
4. you must absolutely guarantee reproducable builds and need a source snapshot of all your dependencies (and their dependencies, etc)

It's probably possible, but seems a bit unnecessary (and somewhat infeasible: how are you going to manage tracking upstream?).

ROS has various tools for managing source checkouts, such as vcstool, wstool and rosinstall_generator.

For binary management and installation -- of both ROS package dependencies as well as system dependencies -- rosdep is used (#q215059).

Setting up a source workspace from a given my_awesome_ros_application.rosinstall file (which only contains references to source repositories of your own packages or forks of upstream packages) is a matter of:

# init only needed once, update regularly
$ sudo rosdep init && rosdep update
$ source /opt/ros/$distro/setup.bash

# create and populate workspace (done once)
$ mkdir $HOME/catkin_ws && cd $HOME/catkin_ws
$ wstool init -j8 $HOME/catkin_ws/src http://location/of/your/my_awesome_ros_application.rosinstall
$ rosdep install -y --from-paths $HOME/catkin_ws/src --ignore-src -y

At this point you'll have your entire system setup to start developing on the packages. Change management can be done per repo, or when using vcstool per workspace.

My suggestion would be to store only the source repositories of your own packages (not the entire catkin_ws, #q264600), and deploy dependencies from the binary repositories as much as possible. Using released binaries is preferably preferable in any case, unless:

1. there are no binaries available (because the pkg has not been released, in general, for your platform / cpu arch, or a particular version is no longer / not yet available)
2. you need a source checkout as you want to work on the actual pkg itself
3. you deploy to systems that absolutely cannot use released binaries
4. you must absolutely guarantee reproducable builds and need a source snapshot of all your dependencies (and their dependencies, etc)