setup-dev-env.sh Script Complaints and Suggestions

[xmfcx]

Hi everyone,

I'm thinking about simplifying and modernizing the setup-dev-env.sh - ansible - docker trio.

And wanted to start from the setup-dev-env.sh file.

General complaints

❓▶️ I would like to know if you have any complaints or suggestions about this script, how it could be improved etc.

Here is my breakdown on this script

• I think that this script is a bloated wrapper around ansible.
• What it does:
  • Basically it installs ansible's dependencies and ansible.
  • Passes variables to ansible and calls ansible in a brittle way.
• Why do this? Why not separate out these 2 steps and just let the users call ansible directly after installing it dependencies?
• We could simplify it and stop maintaining these passed parameters.

Target audience for this script

autoware/setup-dev-env.sh

Line 164 in 447f0e1

apt-get -y install sudo

Here I see that it is installing sudo with apt-get -y install sudo.

I assume it is expecting the caller to have root privileges.

If you run docker run -it ubuntu:22.04 bash then you don't have sudo and you start as root. So it would make sense.

But within docker run -it ros:humble-ros-base-jammy bash it comes with sudo already.

And normal users with desktop have it too. So this sudo installation doesn't make sense to me since our target use cases have it installed by default. Why not remove this step??

❓▶️ Does anyone know what are the use cases for this setup script?

So far I could identify 2 users:

• Normal Ubuntu 22.04 desktop users calling it from an interactive terminal
• ros:humble-ros-base-jammy base container users (for building the docker image)

cc. @mitsudome-r @youtalk @oguzkaganozt @isamu-takagi @maxime-clem @mojomex @VRichardJP

[doganulus]

That script should never have existed over ansible.

Like rosdep should have never existed over apt.
Like ament should have never existed over cmake.

It is never too late.

[VRichardJP]

As any abstraction layer, it is nice until it doesn't do what you want. I guess this is the point @doganulus is trying to make.

At work, we mostly develop using bespoke docker containers built on top of the official ones.

We only use this script to setup new vehicles from scratch, which is certainly not something we do very often.

I don't think we ever had issue with this script. I personally hate shell scripts, so I would not mind if instead we had to copy paste an Ansible one-liner.

[xmfcx]

Yeah, we could have just a very basic install_ansible.sh that installs pipx and ansible, no parameters needed.

Then we can call the ansible with parameters as usual, instead of calling this proxy script with parameters.

Also we can look into setting up a default inventory for variables but these can be done as we go forward.

Like:
vars/defaults.yml

prompt_install_nvidia: false
cuda_install_drivers: true
ros2_installation_type: desktop
data_dir: "{{ lookup('env', 'HOME') ~ '/autoware_data' }}"

vars/local.yml (developer/CI overrides)

# optional, gitignored
prompt_install_nvidia: true
ros2_installation_type: ros-base

But I will open up a discussion for this part separately if we can get somewhat of a consensus on this setup_dev_env.sh script.

---

Also I'm not sure why we are stuck with ansible 6.* so will look into what goes wrong if we use the latest ansible.

[doganulus]

You need to ask users to install ansible (minimally anisble-core) from their package manager or pip and distribute your Ansible scripts (Autoware Ansible Collection) via Ansible Galaxy.

Here is our entry for Autoware Challenge 2023 proposal, maybe still useful for some: https://docs.google.com/document/d/1ZELu47YN2Hq13sXjCXmzJ9YYh1aDqr4jeWLWJ9TrDRQ/edit?tab=t.0

Unfortunately, I do not have the capacity to deal with ROS anymore.

[mitsudome-r]

For apt-get -y install sudo, we might need if for Evaluator setup. I will confirm with the evaluator developers.