I took at this locally, and it's generating the files correctly with the contents I would expect.

Do you know if there is any case of a package exporting non-default values of the PATH or LD_LIBRARY_PATH environment variables? I did a quick find/grep and couldn't find anything that looked non-default.

I would assume that would have some impact on the generated DSV files, in that case.

My other general comment would be to document/expand dsv at least once somewhere for clarity (and specify that the delimiter is a ;). I figured it out from the other issue, but local context would be helpful.

Do you know if there is any case of a package exporting non-default values of the PATH or LD_LIBRARY_PATH environment variables?

What do you mean by "non-default values" in this context?

A package where PATH is exported to something other than bin, or is that always the case?

In general a package can provide any arbitrary environment hook. For it to be also "fast" it should also provide a .dsv file in the future.

Currently the name of the environment hook is used to determine which .dsv file to generate. But maybe we should decouple that instead to not match a custom provided hook by accident?

But maybe we should decouple that instead to not match a custom provided hook by accident?

Commonly these custom hooks have different names (see e.g. ros2/yaml_cpp_vendor#7 and ros2/rviz#449). If they would use the same name they would already overwrite the same file if a "default" hook is already being generated. So I am not sure if any change is necessary here.