Ruby Library Packages
- Creating and Adding Packages to the Workspace
- Integrating 3rd-party libraries
- Package Dependencies
- Type System Plugins
On the C++ side, we have already discussed the separation between the bulk of the implementation in C++ libraries and their framework integration in components.
The same should be applied on the Ruby side of the system. A lot of the functionality needed to e.g. look at diagnostics data streams from the components can be made framework-independent (i.e. Syskit independent). It is somehow weaker in the Ruby case though, as in the end most of the data processing is done in C++ in a Rock system.
For code meant to be executed within Syskit, generally speaking, do not do too many things within the Syskit process. Syskit is in charge of coordinating the system's components, and having long computations within the Syskit process will increase Syskit's reaction times.
Creating and Adding Packages to the Workspace
This is covered in the Workspace and Packages section
Executive Summary: You need to first pick a category and a name the workspace conventions for information about how to name your library package.
The Ruby packages are expected to follow the de-factor standard Ruby package
layout set forth by RubyGems. The best way to create a new ruby package is to
bundle gem and add
manifest.xml to it.
When using VSCode, the package will not be picked up by the
until it is part of the main manifest.
Adding the package path to the layout section of
enough at this stage. You will however have to define the
package in the autobuild and
files before you push the updated manifest to your team members. For instance,
tools/timeseries one would do
bundle gem tools/timeseries <create tools/timeseries/manifest.xml>
and then add
layout: - ... - tools/timeseries
rake within the package during the build, which means that
it runs the
Integrating 3rd-party libraries
External gems can be installed by autoproj using the osdeps
mechanism. For now, autoproj does not know
how to look at a package's gemspec (which defines the gem's dependencies), so
you will have to duplicate dependencies between the gemspec and the
You may also install them in the workspace if you plan to work on them. You
would however have to declare their path manually within
to make sure the checked out repository is used:
gem 'timeseries', path: File.expand_path(File.join('..', 'tools', 'timeseries'), __dir__)
It is common for packages to depend on other packages.
When adding a dependency to a Ruby package, you must add it to the
manifest.xml file. If you do mean to distribute your Ruby package
as a RubyGem, you will also have to modify the bundler-generated
Testing is now an integral part of modern development process, and Rock provides support to integrate unit testing in the development workflow.
Ruby packages are expected to provide a
test target in their
Rakefile to run
the tests. The
Rakefile generated by
bundle gem has one.
Rock's preferred test framework is
minitest and mocking framework is
Type System Plugins
In order to smooth the interface between the Rock type system and the Ruby
layers, one can provide a
typelib_plugin.rb file within a Ruby
package. Just put the file under your package's main directory (e.g.
lib/mypackage/typelib_plugin.rb) to have it automatically loaded.
Let's go now to the Rock specific part of functionality integration, components