Dependency installation enhancement

[ar13pit]

Problem
Our current system first uses a install.yaml and then a install.bash to install a target. With this some targets that are needed as a immediate dependency in install.bash are either installed using the tue-install-x-now commands or bypassed totally by using commands like sudo apt-get install ....

The reason being we collect all package manager based targets in a list to be installed at the end of the execution. This was done to avoid installation at every parse of install.yaml and has made a mess in dependency installation with tons of tue-install-now commands.

We need something in between the two approaches.

Possible solutions:

1. When both install.yaml and install.bash are detected for a target, then flush the current list of targets to be installed at the end by installing them at that instant.
2. Only install the dependent targets at that instant when both install.yaml and install.bash are present and rest at the end of the execution.

Expected result

• Removal of all tue-install-x-now commands
• All target dependencies specified using install.yamlonly
• Cleaner install.bash with no dependency installations commands

[ar13pit]

@MatthijsBurgh @Timple need your thoughts on this. As this is the biggest issue when moving to python and extending support for OS other than Ubuntu.

[Timple]

Current situation is basically declaring dependencies for it's script (albeit nobleo-system-now instead of something like uses)
But I'm okay with the proposed approach if that helps in the tooling. I'm also curious to the timing differences between these to commands:
apt install item1 item2 item3 item4
apt-install item1 item2 && apt install item3 item4

---

Regarding extending support for anything other than Ubuntu: why? This creates a lot of maintenance work. There is a reason even ROS until recently only supported ubuntu officially.

[ar13pit]

There won't be any change in the execution logic if we use the second option. But it will simplify the target creation process largely. With the first option, the execution becomes as you mentioned.

---

I'm not suggesting that we support any other OS other than Ubuntu at the moment. But at Avular I'm first moving melodic packages to noetic and eventually to ROS2. For ROS2 I want to try having this toolkit and extending it to other OS using a plugin based system like colcon does, instead of writing something new. So with a bit of refactor here that should be possible.

[Timple]

Ah, alright. I'm game!

[Timple]

In the meantime at another company not that far away...

We've solved the issue by supporting system-now types in the yaml. Want me to backport that?

[ar13pit]

@Timple Yeah definitely :)

I recently added Docker-in-Docker support for GitLab CI with private repositories, private docker registries and CI config inheritance. Want me to backport that? 😆

[Timple]

That does sound really interesting!
But we use bitbucket, so not sure how relevant that would be...

[ar13pit]

What about the CI? BitBucket itself or something else?

[Timple]

Bitbucket pipelines

[Timple]

@Timple Yeah definitely :)

#513

As the install yamls are parsed top-to-bottom this makes sure dependencies are installed before required

[MatthijsBurgh]

I think this is (partly) fixed by #524