Unit test friendly folder structure for Python examples

[sea-bass]

Attempts to address #233 by moving files around so that there is no module that could be wrongly imported in the source folder of the Python example package.

Turns out the key is to just not have an __init__.py file in the module in the source folder, but instead to generate it only into install space.

... and just as before, if you install with --symlink-install, the __init__.py file will be thrown into the source folder anyhow.

[sea-bass]

to be fixed in #236, but needed for this PR to work properly

[christophfroehlich]

Sorry, I don't have much experience with python install stuff to review that 🤷‍♂️

[sea-bass]

Sorry, I don't have much experience with python install stuff to review that 🤷‍♂️

No worries, I'm hoping the handful of people engaged in the associated issue will get a chance to test here. I just can't officially tag most of them as reviewers as they are not repo collaborators.

[MarqRazz]

Tested locally with my own package and this fixes my testing issues.

[bmagyar]

Much needed, thank you!

[sea-bass]

@christophfroehlich could you give me a green approve on behalf of Marq and Bence, so I can merge this and cut the release? 🙏🏻

[imcelroy]

@sea-bass I'm sorry I'm late, I see this has already been merged!

I left a comment on the issue #233 (comment). I might be missing something, but removing the __init__.py doesn't seem to be standard practice. The python documentation says to put it in the source, ROS examples and the ROS CLI (ros2 pkg create) will put it in the source folder (here), etc, so I'm not sure this is a good long-term solution.

Additionally, it's true that package does successfully build, but I now have the following stderr, which also suggests that this isn't standard practice:

--- stderr: generate_parameter_module_example                                                                                     
package init file 'generate_parameter_module_example/__init__.py' not found (or not a regular file)
---
Finished <<< generate_parameter_module_example [2.32s]

In any case, thank you very much for your reactivity and work on this issue!

[sea-bass]

Oh, interesting. I had not seen that warning for some reason. That is... not ideal.

Yeah, it's a problem because this isn't a "regular" Python module where all the code is available in the source folder.

I guess if we go back to the state before this PR, the only bulletproof way to test these generared modules is to do it from another package.

Anyways, would suggest we keep iterating and if we find something good we can release again. Thanks!

[imcelroy]

Oh, interesting. I had not seen that warning for some reason. That is... not ideal.

Yeah, it's a problem because this isn't a "regular" Python module where all the code is available in the source folder.

I guess if we go back to the state before this PR, the only bulletproof way to test these generared modules is to do it from another package.

Anyways, would suggest we keep iterating and if we find something good we can release again. Thanks!

@sea-bass I agree with iterating. I only wanted to point out that this will break existing unit tests for users that are trying to adopt generate_parameter_library into an existing ROS2 python package (like myself) after having followed ROS guidelines.

I think part of the issue is that the generated parameter module is treated as something "compiled" like in C++. However, from what I understand that isn't how Python works, which is why everything is in the source folder.

As a potential solution to the source control issue that you mentioned here: #233 (comment), the user could add it to their .gitignore.

Thank you again for your help!