normalize paths before comparison in rosmsg

[kejxu]

this is a minor update to the existing results[0] != path: comparison:
normalize all paths before comparison or adding them into paths to make sure all elements in paths are really unique

• _get_package_paths will return 2 paths for the same package; for example: C:\\ros-win\\install_isolated\\share\\test_rosmaster and C:/ros-win/install_isolated\\share\\test_rosmaster will both be returned for test_rosmaster, resulting in duplicated output

[dirk-thomas]

Undefined variable path_in_workspaces?

[kejxu]

embarrassed, change to use results[0]

[dirk-thomas]

The duplication of control seems unnecessary. This could simple stay a single condition since on platforms where os.path.sep is / the replace() calls are no-ops:

if results and results[0].replace(os.path.sep, '/') != path.replace(os.path.sep, '/'):
    paths.append(results[0])

[dirk-thomas]

Thanks for the patch.

[kejxu]

@dirk-thomas, thanks for merging this change! While not related to this change, here is something I'd love to share and ask for opinions:

the reason for the test failure behind this change is essentially because 1 path is normalized, and the other one is not. this normalization happens during https://github.com/ros/ros_comm/blob/melodic-devel/tools/rosmsg/src/rosmsg/__init__.py#L551

path = rospack.get_path(pkgname)

and inside rospack.get_path, abspath is called

path = os.path.abspath(path)

from python documentation:

os.path.abspath(path)
Return a normalized absolutized version of the pathname path. On most platforms, this is equivalent to calling the function normpath() as follows: normpath(join(os.getcwd(), path)).

I haven't had time to dig in further on the behavior of abspath on Linux, but given our experience working with symlinks, I feel like this might be worth looking into. ROS should probably consider to

• normalize all paths (if this would also make sense with the presence of symlinks)
• or, avoid any normalization (which might make sanitizing paths very painful)

[dirk-thomas]

Due to the size of the code base I can't suggest either of the two approaches. Just blindly applying normalization doesn't sounds appealing to me. Removing it from that specific instance might have unintended side effects. I guess it would need to be tried...