search

BEAMRobotics / beam_robotics

Parent Directory for all code used with Beam Robotics
2 stars 0 forks source link

Refactor dependencies #92

Closed adthoms closed 2 years ago

adthoms commented 2 years ago

Having dependencies as submodules is clunky. Right now, anytime we update libbeam, the velodyne driver, etc. we have to commit these change in beam_robotics. Dependencies currently in beam_robotics will be installed via wstool in similar fashion to how Kimera-ROS does it. This way, any dependencies will be cloned as their own repos

nickcharron commented 2 years ago

@adthoms I'm not conviced wstool is going to make this any easier. I think that makes sense if your dependencies are production code, i.e., very stable and released slowly by major version releases.

This is just a common problem that is a bit unavoidable when you have multiple dependent packages being worked on together. The best approach is a meg repo, so people are forced to keep everything up to date, and you can't commit something that breaks dependent code (hence why all big tech companies do this). But that causes problems with ownership and releasing individual components.

I think the submodules is the least painful option if we want to keep this "master repo" with all our main code. If we find that people are only using one or two pieces of beam_robotics (say inspection, libbeam, and calibration) then maybe just 3 separate repos is fine. But any more than that I think warrants having this mega repo with submodules.

Thoughts @jakemclaughlin6 ?

nickcharron commented 2 years ago

It's also kinda nice because having beam_robotics kinda tracks what code is actually working/maintained.

Think about it, we have 70 repos in BEAMRobotics org. Most of them are forks from others, or code that we never fully got working, or code we have stopped maintaining.

So if we didn't have beam_robotics, then (1) people wouldn't know what repos actually have good usable code, and (2) people wouldn't know what dependencies they should check to make sure their changes don't break code currently being used/maintained

jakemclaughlin6 commented 2 years ago

I think separating some of the larger folders into repositories of their own then adding them as submodules would be a good middle ground. I think inspection tools and calibration should definitely have their own repos. Then maybe we clean up some of the repo like map processing is unused and I think we have some unused drivers/depenencies