tl_expected and libexpected-dev provide overlapping headers on Ubuntu 24.04

[otamachan]

Hi, thanks for maintaining this great library!

Problem

Starting with Ubuntu 24.04 (Noble), the libexpected-dev package (v1.1.0) is available from the official Ubuntu repository. This package installs the header at /usr/include/tl/expected.hpp.

Meanwhile, generate_parameter_library depends on the ROS tl_expected package, which installs the same library at a different path: <prefix>/include/tl_expected/expected.hpp.

Both headers are from the same upstream project (TartanLlama/expected) but at different versions:

Package	Version	Include path
libexpected-dev (Ubuntu 24.04)	1.1.0	tl/expected.hpp
ros-jazzy-tl-expected (ROS)	1.0.1	tl_expected/expected.hpp

Both headers use the same header guard (TL_EXPECTED_HPP) and the same namespace (tl), so whichever is included first silently suppresses the other. This can cause subtle version mismatch issues and confuses tools like IWYU (include-what-you-use) about which path is canonical.

Since generate_parameter_library generates code that users include in their own packages, this issue affects all downstream consumers — not just this library itself. Any package using a generated parameter library will transitively pull in tl_expected/expected.hpp via rsl/parameter_validators.hpp and parameter_traits/parameter_traits.hpp, potentially clashing with the user's own tl/expected.hpp usage without them being aware of it.

The generated code template itself does not directly include tl_expected/expected.hpp. The dependency comes through rsl (via rsl/parameter_validators.hpp) and parameter_traits (via parameter_traits/parameter_traits.hpp). Since generate_parameter_library generates code that users include in their own packages, this transitively pulls in tl_expected/expected.hpp to all downstream consumers, potentially clashing with the user's own tl/expected.hpp usage without them being aware of it.

Suggestion

Consider migrating from the ROS tl_expected package to the Ubuntu system package libexpected-dev (rosdep key: libexpected-dev), at least for Jazzy and later (Ubuntu 24.04+). This would:

• Eliminate the dual-installation conflict
• Align with the system package that Ubuntu users may already have installed
• Use a newer version (1.1.0 vs 1.0.1)

This would involve changing the include path from <tl_expected/expected.hpp> to <tl/expected.hpp> in rsl, parameter_traits, and generate_parameter_library.

Environment

• ROS 2: Jazzy
• Ubuntu: 24.04 (Noble)
• libexpected-dev: 1.1.0-2
• ros-jazzy-tl-expected: 1.0.1

[otamachan]

I looked into the generated code template and found that it doesn't directly include tl_expected/expected.hpp. The dependency comes through rsl (via rsl/parameter_validators.hpp) and parameter_traits (via parameter_traits/parameter_traits.hpp).

So the root dependency on tl_expected is actually in rsl (https://github.com/PickNikRobotics/RSL), not in the generated code itself.

[christophfroehlich]

Thanks for reporting.

I see that 1.0.0 is released for jammy as well: https://packages.ubuntu.com/jammy/libexpected-dev
and you have added the rosdep key ros/rosdistro#45164 already.

It seems that it is available on all unix-based target platforms, what about windows?

Do we need tl_expected for the generate_parameter_library package at all?
I suppose we can remove it with #294. It will only be used in the example (which is not released).

Necessary steps then:

• Deprecate it in cpp_polyfills
• Switch RSL to use libexpected-dev
• Remove tl-expected from GPL package
• Update README and example to use libexpected-dev

[otamachan]

Thanks for the quick response and the detailed plan!

Regarding Windows: I'm not very familiar with the Windows build setup for ROS2. I did find that tl-expected v1.1.0 is available on vcpkg, but I'm not sure how dependency resolution works on the Windows side of rosdep.

The plan you outlined sounds great to me. Let me know if there's anything I can help with.

[christophfroehlich]

could you open a PR for RSL with the necessary changes please?

[otamachan]

Created a PR for RSL: PickNikRobotics/RSL#151