Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

This will likely become obsolete with the release of Noetic, but as I've just had to build a version of Kinetic with Python 3 support (for the Nth time), I figured I'd post the commands I've used here (for myself as well).

This is a more copy-pastable version of @v4hn's answer (but was too long for a comment).

Assumptions:

  • OS: Ubuntu Xenial (16.04)
  • ROS Kinetic is already installed on that system (the .deb distributed version)

I always use a virtual environment, as it's typically the case that besides ROS, there are Python modules that need to be installed one might not want to "pollute" the system with.

Notes:

  1. this only builds a bare-bones ROS Kinetic with Python 3. No Open CV or other 'complex' packages/nodes. For many use-cases this is already quite sufficient though.
  2. as such, this is not an answer to the general problem of how to build all of ROS 1 with Python 3 support.

In any case, as follows:

# create a place for our Python3-ROS-Kinetic to live
mkdir $HOME/rospy3_kinetic
cd $HOME/rospy3_kinetic

# make sure these are installed
apt install python3-venv libpython3-dev python-catkin-tools

python3.5 -m venv venv3.5_ros
source venv3.5_ros/bin/activate

# these modules are needed but are not automtically installed
pip3 install wheel empy defusedxml netifaces

# just the standard build-ros-from-source dependencies
pip3 install -U rosdep rosinstall_generator wstool rosinstall

# seed the workspace with a 'ros_base' set of packages
rosinstall_generator --deps --tar --rosdistro=kinetic ros_base > ros_base.rosinstall
wstool init src -j8 ros_base.rosinstall

# the following is somewhat optional: if you already are confident you have
# the main dependencies you could skip this

# this may fail if you already have done this, in that case: ignore
sudo rosdep init
rosdep update

# I use check here to first see what is missing. If missing dependencies are
# serious enough, install manually or use 'install' verb
rosdep check --from-paths src/ -i

# finally build the workspace, while:
#  - disabling testing globally
#  - making sure optimisations are enabled ('Release' build type)
#  - forcing use of Python 3.5
catkin build -DCATKIN_ENABLE_TESTING=0 -DCMAKE_BUILD_TYPE=Release -DPYTHON_VERSION=3.5

At this point source the setup.bash of the workspace. You may choose to configure catkin_tools to create an install space instead of using the devel space directly.

For regular usage you'll need to make sure to have the virtual environment activated, or things will break.

I'd recommend using workspace overlaying for actual development.

This will likely become obsolete with the release of Noetic, but as I've just had to build a version of Kinetic with Python 3 support (for the Nth time), I figured I'd post the commands I've used here (for myself as well).

This is a more copy-pastable version of @v4hn's answer (but was too long for a comment).

Assumptions:

  • OS: Ubuntu Xenial (16.04)
  • ROS Kinetic is already installed on that system (the .deb distributed version)

I always use a virtual environment, as it's typically the case that besides ROS, there are Python modules that need to be installed one might not want to "pollute" the system with.

Notes:

  1. this only builds a bare-bones ROS Kinetic with Python 3. No Open CV or other 'complex' packages/nodes. For many use-cases this is already quite sufficient though.
  2. as such, this is not an answer to the general problem of how to build all of ROS 1 with Python 3 support.

In any case, as follows:

# create a place for our Python3-ROS-Kinetic to live
mkdir $HOME/rospy3_kinetic
cd $HOME/rospy3_kinetic

# make sure these are installed
apt install python3-venv libpython3-dev python-catkin-tools

python3.5 -m venv venv3.5_ros
source venv3.5_ros/bin/activate

# these modules are needed but are not automtically installed
pip3 install wheel empy defusedxml netifaces

# just the standard build-ros-from-source dependencies
pip3 install -U rosdep rosinstall_generator wstool rosinstall

# seed the workspace with a 'ros_base' set of packages
rosinstall_generator --deps --tar --rosdistro=kinetic ros_base > ros_base.rosinstall
wstool init src -j8 ros_base.rosinstall

# the following is somewhat optional: if you already are confident you have
# the main I like to run this to see if
# something obvious is missing, but we can't ask rosdep to 'install'
# things for us: it will try to use apt to install the Python 2 version
# of all dependencies you could skip this
it sees missing.

# this may fail if you already have done this, in that case: ignore
sudo rosdep init
rosdep update

# I use check here to first see what is missing. If missing dependencies are
# serious enough, use 'pip3' to install manually or use 'install' verb
into the virtual environment for
# Python dependencies, 'apt' for any other dependencies
rosdep check --from-paths src/ -i

# finally build the workspace, while:
#  - disabling testing globally
#  - making sure optimisations are enabled ('Release' build type)
#  - forcing use of Python 3.5
catkin build -DCATKIN_ENABLE_TESTING=0 -DCMAKE_BUILD_TYPE=Release -DPYTHON_VERSION=3.5

At this point source the setup.bash of the workspace. You may choose to configure catkin_tools to create an install space instead of using the devel space directly.

For regular usage you'll need to make sure to have the virtual environment activated, or things will break.

I'd recommend using workspace overlaying for actual development.

This will likely become obsolete with the release of Noetic, but as I've just had to build a version of Kinetic with Python 3 support (for the Nth time), I figured I'd post the commands I've used here (for myself as well).

This is a more copy-pastable version of @v4hn's answer (but was too long for a comment).

Assumptions:

  • OS: Ubuntu Xenial (16.04)
  • ROS Kinetic is already installed on that system (the .deb distributed version)

I always use a virtual environment, as it's typically the case that besides ROS, there are Python modules that need to be installed one might not want to "pollute" the system with.

Notes:

  1. this only builds a bare-bones ROS Kinetic with Python 3. No Open CV or other 'complex' packages/nodes. For many use-cases this is already quite sufficient though.
  2. as such, this is not an answer to the general problem of how to build all of ROS 1 with Python 3 support.

In any case, as follows:

# create a place for our Python3-ROS-Kinetic to live
mkdir $HOME/rospy3_kinetic
cd $HOME/rospy3_kinetic

# make sure these are installed
apt install python3-venv libpython3-dev python-catkin-tools

python3.5 -m venv venv3.5_ros
source venv3.5_ros/bin/activate

# these modules are needed but are not automtically automatically installed
pip3 install wheel empy defusedxml netifaces

# just the standard build-ros-from-source dependencies
pip3 install -U rosdep rosinstall_generator wstool rosinstall

# seed the workspace with a 'ros_base' set of packages
rosinstall_generator --deps --tar --rosdistro=kinetic ros_base > ros_base.rosinstall
wstool init src -j8 ros_base.rosinstall

# the following is somewhat optional: I like to run this to see if
# something obvious is missing, but we can't ask rosdep to 'install'
# things for us: it will try to use apt to install the Python 2 version
# of all dependencies it sees missing.

# this may fail if you already have done this, in that case: ignore
sudo rosdep init
rosdep update

# I use check here to first see what is missing. If missing dependencies are
# serious enough, use 'pip3' to install into the virtual environment for
# Python dependencies, 'apt' for any other dependencies
rosdep check --from-paths src/ -i

# finally build the workspace, while:
#  - disabling testing globally
#  - making sure optimisations are enabled ('Release' build type)
#  - forcing use of Python 3.5
catkin build -DCATKIN_ENABLE_TESTING=0 -DCMAKE_BUILD_TYPE=Release -DPYTHON_VERSION=3.5

At this point source the setup.bash of the workspace. You may choose to configure catkin_tools to create an install space instead of using the devel space directly.

For regular usage you'll need to make sure to have the virtual environment activated, or things will break.

I'd recommend using workspace overlaying for actual development.