Design intent of setup.sh vs setup.bash about colcon-core HOT 4 OPEN

Colcon-core generates multiple scripts in the install directory such as:

install.bash
install.sh

The install.bash is generated by colcon-bash, not colcon-core. The only "native" shells that colcon supports are "sh" and "bat". There are extensions to enable Powershell, Bash and Zsh. All three of the additional shells are part of colcon-common-extensions.

Developers can easily make assumptions that certain commands are always available, such as head.

This might be nitpicky, but I'm not sure what this particular example has to do with the shell. head and cut are both standalone executables provided by coreutils on both Fedora and Debian. What and how busybox chooses to implement these "core" executables doesn't seem like something we should be concerned with here, no?

We can't declare dependencies on system packages from pure python packages, but we could probably add the dependency to the debs. From the sounds of it, that won't help the other (minimalistic) Linux distros you're discussing though.

For this specific case, if there's a clean way to switch from head to cut to appease busybox without regressing other platforms, I'd love to see a PR.

from colcon-core.

Would it be OK to request that colcon-core be modified to work better on busybox that does not come with the same form of coreutils as long as functionality to other distros is not impacted?

I see no reason to reject a change that doesn't regress existing platforms and doesn't unnecessarily increase maintenance burden.

... the OE working group doesn't have CI for anything yet, but this is something that could be contributed to colcon-core ...

I think we could consider adding another platform if it integrates cleanly into GitHub Actions. All colcon extensions in this org use https://github.com/colcon/ci.

Rob hinted he found a clean solution for the head to cut issue.

Great, looking forward to it.

from colcon-core.

Tangent: If your intent is truly to generate a minimal build environment, you should consider dropping colcon-common-extensions in favor of the specific colcon extensions you need to complete the build.

For example, this is the set of extensions present on ci.ros2.org builds: https://github.com/ros2/ci/blob/403b3445ee7e7253dd6c24b042feb3ae584dce76/ros2_batch_job/__main__.py#L86-L109

from colcon-core.

Great information! Thank you for the speedy feedback.

I understand colcon is intended to be more portable than ROS which is focused mainly on the tier 1 distributions.

Would it be OK to request that colcon-core be modified to work better on busybox that does not come with the same form of coreutils as long as functionality to other distros is not impacted? We can do the PR's as needed.

For long term maintenance, the OE working group doesn't have CI for anything yet, but this is something that could be contributed to colcon-core to support longer-term maintenance on busybox systems once we figure out how to do it.

Rob hinted he found a clean solution for the head to cut issue. We're not sure how many more changes there would be, but this kind of support to colcon would help it be used in more minimal OS's.

from colcon-core.