|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
| Name | Deps |
|---|---|
| mola | |
| mola_kernel | |
| mola_lidar_odometry |
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged mola_yaml at Robotics Stack Exchange
|
mola_yaml package from mola repomola mola_bridge_ros2 mola_demos mola_input_lidar_bin_dataset mola_input_rawlog mola_input_rosbag2 mola_input_video mola_kernel mola_launcher mola_metric_maps mola_msgs mola_pose_list mola_relocalization mola_traj_tools mola_yaml |
ROS Distro
|
Package Summary
| Version | 3.2.0 |
| License | BSD-3-Clause |
| Build type | CMAKE |
| Use | RECOMMENDED |
Repository Summary
| Checkout URI | https://github.com/MOLAorg/mola.git |
| VCS Type | git |
| VCS Version | develop |
| Last Updated | 2026-08-25 |
| Dev Status | DEVELOPED |
| Released | RELEASED |
| Contributing |
Help Wanted (-)
Good First Issues (-) Pull Requests to Review (-) |
Package Description
Additional Links
Maintainers
- Jose-Luis Blanco-Claraco
Authors
mola_yaml
YAML helper library common to MOLA modules. A C++ library to parse YAML files with extended syntax allowing variable replacing, recursive includes of other YAML files, etc.
Build and install
Refer to the root MOLA repository.
Docs and examples
See this package page in the documentation.
License
This package is released under the BSD-3 license.
Changelog for package mola_yaml
3.2.0 (2026-08-21)
- Merge remote-tracking branch 'origin/feat/map-frame-gauge-change' into feat/map-frame-gauge-change
- Merge branch 'develop' into feat/map-frame-gauge-change
- Contributors: Jose Luis Blanco-Claraco
3.1.1 (2026-08-10)
3.1.0 (2026-08-06)
- Merge pull request #187 from MOLAorg/feat/incremental-point-cloud-kdtree-bake Bake IncrementalPointCloud's k-d tree index (mm-ipc-bake-kdtree)
- changelog
- Merge pull request #182 from MOLAorg/fix/yaml-define-outer-wins fix(mola_yaml): outer $define wins over a more deeply imported file's own $define
- style: apply clang-format-14 to the outer-wins $define fix
- fix(mola_yaml): outer $define wins over a more deeply imported file's own $define Nested $define blocks for the same variable name did not compose the way $import sibling overrides do: the more deeply imported file's own $define silently won, discarding an outer file's override for that same name. This made it impossible for a launcher to retune a hook that a reusable imported fragment also $defines its own default for, short of restating the whole target key as a literal sibling value. consumeDefineBlock() now skips a $define entry whose name is already present in the inherited scope, so the scope closest to the document root (or the caller's initial variables) has final say, mirroring "environment > $define > inline default" one level up. Updated the existing nested-$define test to the new (opposite) contract and added a dedicated multi-level $import regression test for the exact reusable-fragment shape that surfaced this.
- Merge pull request #181 from MOLAorg/feat/yaml-define-directive mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree
- docs: clarify outer scope only is used to expand vars
- mola_yaml: new [$define]{.title-ref} directive to set variables for a subtree Shared pipeline files already expose their tunable settings as [${VAR|default}]{.title-ref} hooks, but until now a launcher had no way to drive them from the YAML itself: the value had to come from the real environment. Working around that meant duplicating whole blocks after an [$import]{.title-ref} just to change one nested field, which is especially painful for values inside a YAML sequence, since [$import]{.title-ref}'s deep-merge replaces sequences wholesale. [$define]{.title-ref} is a map key holding [NAME: VALUE]{.title-ref} pairs that are bound as [${NAME}]{.title-ref} variables for the subtree of the map it appears in, including the files pulled in by a sibling [$import]{.title-ref} / `$include{}[: $define: MOLA_DESKEW_METHOD: "MotionCompensationMethod::IMU" $import: lidar3d-default.yaml The bindings go into `YAMLParseOptions::variables]{.title-ref}, so the resolution order in parseVars() is unchanged and the effective priority is `environment > $define > inline |default`: a variable exported on the command line still overrides the file. This is deliberately not a setenv: the scope is the YAML subtree, so nothing leaks into the process environment, into [$()]{.title-ref} sub-processes, or into a sibling module's import. Since the variable pass runs later over the whole document with the outer options, a subtree carrying a [$define]{.title-ref} is expanded eagerly so the definitions reach the plain sibling keys too, not only the imported files. Includes unit tests and user documentation.
- Contributors: Jose Luis Blanco-Claraco
- feat: new [$define]{.title-ref} YAML directive to bind variables for a subtree (including imported files), letting launchers tune shared pipeline settings without duplicating blocks.
- fix(mola_yaml): an outer file's [$define]{.title-ref} now correctly wins over a more deeply imported file's own [$define]{.title-ref}.
- Contributors: Jose Luis Blanco-Claraco
3.0.0 (2026-07-17)
- docs: list all debug/trace env variables
- Merge pull request #161 from MOLAorg/feat/yaml-import-override feat(mola_yaml): $import map directive for base-file + overrides
- feat(mola_yaml): add $import map directive for base-file + overrides A map with an [$import]{.title-ref} key (a path, or a sequence of paths) is replaced by the deep-merge of the imported file(s) with the map's remaining keys overlaid on top, so sibling entries OVERRIDE the imported base (nested maps merge deeply; scalars/sequences replace). This complements [$include{}]{.title-ref} (which replaces a whole node) and lets near-identical launch files share a common params block while tweaking just a few values, instead of duplicating it. - Resolved in the same first pass as [$include{}]{.title-ref}, reusing its path pre-processing, relative-path resolution and circular-reference detection. - Unit tests: single import, multi-file sequence (later file wins), sibling override including deep-nested, load_yaml_file path, and missing-file throw.
File truncated at 100 lines see the full file