Publish isc versions of serial and serial utils to ros repos

[andyblarblar]

Now that we have an isc fork of both serial libs, we should publish both a ros1 and ros2 version of each to the ros repos. This will allow for us to remove these two from the vcstool repos file, and simply obtain them via traditional rosdep dependancy management.

TODO

• [ ] clean up both repos
• [ ] publish both repos to ros repositories under an isc account
• [ ] change all isc repos to use isc serial and serial utils instead of the normal serial, and remove all serial entries in vcstool repos files

[andyblarblar]

Opon futher inspection, it occured to me that this cannot completely replace vcstool, as this does not handle runtime dependancies. Nonetheless, for compile time dependancies such as serial and serial-utils fetchContent solves our issues.

[davidcutting]

The typical method of installing dependencies is with rosdep. Rosdep will look at the package.xml and attempt to apt install all the listed dependencies. vsctool is just to grab dependencies from git which are not available through apt [such as isc repos].

I would recommend you use rosdep and vcstool, as that is the standard way to handle dependencies.

[andyblarblar]

The typical method of installing dependencies is with rosdep. Rosdep will look at the package.xml and attempt to apt install all the listed dependencies. vsctool is just to grab dependencies from git which are not available through apt [such as isc repos].

I would recommend you use rosdep and vcstool, as that is the standard way to handle dependencies.

Really the only thing this issue is for is managing how serial and serial_util are handled, as they are just libraries and also not avalible through rosdep. I have found that using fetch content for these two does work nicely as it removes the need to keep a clone of the repo for every dependancy, but now that we've been forking these two repos anyways I think it may be a better bet to instead just maintain a isc serial and serial utils for ros1/ros2, and publish them to the ros repositiory ourselves. This would allow us to just use rosdep and also make patches to the libaries themselves.

I do maintain that FetchContent should be how we handle non-ros and non-system dependancies, such as fmt or similar general purpose C++ libraries, although we don't use any at the moment from what I can tell.

[davidcutting]

I don't see any problem with using it for non-ros libraries. The only reason why serial/serial_utils are not available on apt is because the original author hasn't pushed it to the ros repository for noetic and ros2. You can make an issue on the authors repo and hope that he adds it for us, but last time an ISC member did this it took a year for the author to respond.

IMO, this implies it is depreciated. For these two repos alone I strongly suggest they're just added to the list of stuff to be cloned by vcstools. It is best to stick as closely to the way that things are typically done in ros as possible, even if there are other solutions. Regardless of how convenient FetchContent is, I'm worried that using atypical solutions for problems that ros has standard tools for will make the project more complex for those who are learning ros, or know ros.

[andyblarblar]

I don't see any problem with using it for non-ros libraries. The only reason why serial/serial_utils are not available on apt is because the original author hasn't pushed it to the ros repository for noetic and ros2. You can make an issue on the authors repo and hope that he adds it for us, but last time an ISC member did this it took a year for the author to respond.

IMO, this implies it is depreciated. For these two repos alone I strongly suggest they're just added to the list of stuff to be cloned by vcstools. It is best to stick as closely to the way that things are typically done in ros as possible, even if there are other solutions. Regardless of how convenient FetchContent is, I'm worried that using atypical solutions for problems that ros has standard tools for will make the project more complex for those who are learning ros, or know ros.

Yeah, I don't disagree with this. Right now we are using vcstool as they are heavily depricated (nearly for a decade now). I would like to remove the need to clone these two, so Ill bring up the possiblity of us publishing a fork of these to the ros repo in the next meeting so we can just use rosdep. Avery has already been using his own fork of serial_utils for yeti anyhow so this would help both teams too as we could make a isc_serial_utils or something that we have a noetic and foxy version of. The only downside to this from my perspective would be changing all of the isc repos to use isc_serial instead of serial, but thats a pretty quick fix.