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

[christophfroehlich]

I thought again about breaking downstream packages with updating this. From your description, both packages do not interfere each other? So what about:

• Additionally to deprecate it in cpp_polyfills, we could add libexpected-dev as package dependency and include a shim from the "old" header file to use the new upstream version?
• Instead of removing tl_expected from RSL package.xml, we add both.

Downstream packages will still compile, but now with the compile-time deprecation warnings, and automatically using the latest release version of libexpected-dev?

[christophfroehlich]

And I saw now that even on noble the released 1.1.0 is not very up-to-date,
From the PR from @sea-bass PickNikRobotics/cpp_polyfills#5 this would mean that we would roll back the version from 1.2.0 to 1.1.0 again. Should we really do this?

[sea-bass]

To make things more fun, I think the official tl_expected repo is like at 1.3.1 now lol

https://github.com/TartanLlama/expected/releases/tag/v1.3.1

[otamachan]

I'm not very familiar with RSL internals, but if RSL requires a newer version of tl::expected beyond what libexpected-dev provides, there may not be much we can do here.

On the other hand, if RSL can migrate to libexpected-dev, I think @christophfroehlich's suggestion to deprecate it in cpp_polyfills is a good approach — emitting warnings for users who still include tl_expected/expected.hpp would help guide a smooth transition.

[christophfroehlich]

I can only comment this from the generate_parameter_library perspective, where we can live with 1.1.0 as well.
@sea-bass had a motivation to bump the version in cpp_polyfills, there might be some users relying on it.

We will end up in the same situation like urdfrom, which is released in debian packages but with versions way behind the actual development as a ROS package.

A different perspective: Is it worth to "vendor" the library via cpp_polyfills and manually pull the updates, who should maintain it? Or try to convince the original author to directly release in in the ROS ecosystem?

[otamachan]

As another possible approach: the generated ParamListener class itself doesn't seem to expose tl::expected in its public API. The only place where users directly interact with tl::expected is in custom validators, which are expected to return tl::expected<void, std::string>. If we replace the custom validator return type with something from the standard library (e.g., std::optional<std::string>), and split the generated code into a header and a .cpp file (moving validator calls and rsl::to_parameter_result_msg() into the .cpp), it might be possible to remove tl_expected/expected.hpp from the public-facing headers entirely. Note that rsl/static_string.hpp and rsl/static_vector.hpp (which would remain in the header) do not depend on tl_expected.

This would be a larger change, but it would eliminate the transitive header conflict described in this issue without requiring changes to RSL itself. I haven't fully verified the feasibility yet — just sharing the idea for discussion.

[christophfroehlich]

Semantically, the tl/std::expected would make more sense. The original authors decided to use this, and I don't dare to question this ;)

This problem will solve itself somewhen in the future when c++23 will be the minimum version for a ROS release, but this will not be the case for the next Lyrical Luth.

Has anyone approached the author of tl_expected if he'd like to push up-to-date releases to the ROS buildfarm?
If this is not the case, my favorite would be to deprecate the "vendor" package in cpp_polyfills to push users to integrate the system library. Only open question is the windows build then, I'll started investigating this.

[otamachan]

Following up on PickNikRobotics/cpp_polyfills#9 (which I came across while looking into this), perhaps the simplest solution would be to update tl_expected/expected.hpp in cpp_polyfills to redirect to the system header when available:

#if __has_include(<tl/expected.hpp>)
// Just redirect with deprecation warning
#pragma message("tl_expected/expected.hpp is deprecated, use tl/expected.hpp instead")
#include <tl/expected.hpp>
#else
// keep existing vendored implementation for platforms without libexpected-dev (e.g., Windows)
...
#endif

This way:

• On platforms where libexpected-dev is available, the system header is used — eliminating the header conflict described in this issue
• On platforms without it (e.g., Windows), the bundled version continues to work as before
• No changes needed in RSL or generate_parameter_library
• Existing #include <tl_expected/expected.hpp> in downstream code keeps working everywhere

Adding libexpected-dev as a dependency in cpp_polyfills' package.xml would also ensure rosdep installs the system package on supported platforms.

[christophfroehlich]

Oh, I haven't seen the mentioned issue until now 🙈
Your solution seems to be the most simple one. But users relying on a newer version of tl_expected can't opt-in the vendored version?