A ROS Package Is a Deployable Unit

A Python file can run by itself.

A ROS 2 package gives ROS tooling a structured way to describe, build, install, discover, and share related code.

The official package tutorial describes a package as the organizational unit for ROS 2 code.

Concept flow

ROS 2 Python code crosses packaging boundaries before it becomes a node

Workspace, package, executable metadata, Python entry point, and runtime node each have different responsibilities.

1. WORKSPACEcontains one or more project packages
   contains
2. PACKAGEpackage.xml and setup metadata define the unit
   installs
3. ENTRY POINTsetup metadata exposes a ros2 run executable
   starts
4. 

   RCLPY CODEPython creates publishers, subscribers, and node behavior
   creates
5. NODEruntime participant appears in the ROS graph

Python package minimum structure

The Jazzy tutorial identifies files/directories including:

my_package/
├── package.xml
├── resource/my_package
├── setup.cfg
├── setup.py
└── my_package/
    └── __init__.py

If the package provides executables, setup.cfg and entry points matter because ros2 run needs installed executable metadata.

Package versus workspace

A workspace can contain many ROS packages.

ros2_ws/
└── src/
    ├── package_a/
    ├── package_b/
    └── robotnix_pubsub/

Do not use "workspace" and "package" as synonyms.

Package versus node

A package can provide multiple executables, and those executables can create nodes.

For this Unit:

robotnix_pubsub package
  ├─ talker executable → /robotnix_talker node
  └─ listener executable → /robotnix_listener node

Checkpoint

Explain the nesting:

workspace → package → executable → node