Removing datamodel_code_generator from main installation step

[aaronchongth]

Bug fix

Fixed bug

Fixes #372.

Fix applied

• remove datamodel_code_generator from installation step as it is not released by binaries, and only emits a warning even when building rmf_api_msgs from source, not crashing the build, as per Missing dependency in building from source #249
• datamodel_code_generator will only be used if a user is trying to create their own api-server via the schemas from rmf_api_msgs, otherwise it is not used at all
• any mentions of datamodel_code_generator will only be in rmf_api_msgs

Verify warning instead of crash

Using podman,

podman run -it docker.io/library/ros:humble-ros-base-jammy

# inside the image
mkdir -p ~/ws/src
cd ~/ws/src
git clone https://github.com/open-rmf/rmf_api_msgs
cd ~/ws
rosdep install --from-paths src --ignore-src --rosdistro humble -y
source /opt/ros/humble/setup.bash
colcon build
# only emits warning, still builds fine

[koonpeng]

Is there another package using datamodel_code_generator? If it is meant for rmf-web it should already be using a fixed version.

[aaronchongth]

There is https://github.com/open-rmf/rmf_api_msgs too, I can update the readme there too.

for rmf-web, I think we are installing into the virtual environment and not system so it shouldn't matter right?

[koonpeng]

There is https://github.com/open-rmf/rmf_api_msgs too, I can update the readme there too.

for rmf-web, I think we are installing into the virtual environment and not system so it shouldn't matter right?

It half matters because rmf-web uses a venv that shares the system packages, the venv packages should have priority but in rare cases there may be problems with the transitive dependencies (actually this also applies to fastapi, uvicorn etc). I don't see any solutions though so this might be the best workaround.

After we merge this, what else do we need to do to make the build farm also use these instructions?

[aaronchongth]

Right now the buildfarm doesn't care, it is actually optional https://github.com/open-rmf/rmf_api_msgs/blob/main/rmf_api_msgs/CMakeLists.txt#L95, to allow folks to use models in python (ok this is rather important still if someone wants to use binaries and python to interact with rmf-web) But right now, nothing needs to be done.

We'll need to start the conversation again, regarding migrating away from pip for anything rmf related.

[koonpeng]

Not ideal but it's the best workaround atm.