Self-contained ROS2 pub/sub system
Hi, I'm wondering if there's any sort of "self-contained" implementation of a ROS2-compatible publisher/subscriber that doesn't require installing ROS, and only depends on pip-installable dependencies? It only needs to be able to send/receive ROS messages (maybe also services) but nothing else.
Also, is there a DDS implementation that can be installed with pip3 install some-python-dds and no other command and it just works?
I looked at https://github.com/atolab/cdds-python
- "pydds depends on" --> FAIL, pip won't know this from a readme
- "Once the dependencies are intalled simply do ... ./configure.linux" --> HORRIBLE FAIL, pip doesn't read english
https://github.com/rticommunity/conne...
- Before building/installing connextdds-py, it is necessary to run the configuration.py script. --> FAIL, pip can't read this
Basic use case here is running a ROS node on a system on which I don't have root access, have very limited disk space, but can install pip packages specified as packagename==version.
really?
A simple: "This doesn't work, as it's not
pipinstallable` would have sufficed.Also: the two projects you mention are Python bindings to regular (ie: C/C++ based) DDS implementations. That's mentioned in their readmes. You cannot use them stand-alone, and they require a properly setup build environment.
Hm, but I suppose they could be statically compiled such that they work with pip, such as pip3 install opencv-python "just works" even though it is C/C++. Same for numpy, tensorflow, etc. which are all C/C++ and fully pippable with no other steps and automagically install dependencies. I feel like the moment one has to say "before installing do X Y Z" you've basically given up on using technology to manage dependencies, going back to the days of Slackware 1.0, and expecting the user to do what tools like pip and apt were invented for. It's 2021, every install should be a one-liner. Nobody should have to read readmes to install release versions of stuff. The whole point is so that I can build software on top of it, reference e.g. cdds-python as a dependency, and my users can install my package with a ...(more)
Could all be, but what's the point of describing everything as horrible fail? That's not really going to incentivise anyone to help you I believe.
I mean I suppose those implementations fail already ;) so it incentivizes other self-contained DDS library authors to come out and advertise themselves. If they don't exist I guess that's incentive for me to try to write one or fork one of the above and make it pippable if their licenses permit ...