Ruby Library Packages
- Creating and Adding Packages to the Workspace
- Integrating 3rd-party libraries
- Package Dependencies
- Tests
- 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
use bundle gem and add
Rock's manifest.xml to it.
When using VSCode, the package will not be picked up by the vscode-rock
extension
until it is part of the main manifest.
Adding the package path to the layout section of autoproj/manifest is
enough at this stage. You will however have to define the
package in the autobuild and source.yml
files before you push the updated manifest to your team members. For instance,
when creating tools/timeseries one would do
bundle gem tools/timeseries
<create tools/timeseries/manifest.xml>
and then add
layout:
- ...
- tools/timeseries
autoproj runs rake within the package during the build, which means that
it runs the Rakefile's default task.
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
manifest.xml.
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 autoproj/Gemfile
to make sure the checked out repository is used:
gem 'timeseries', path: File.expand_path(File.join('..', 'tools', 'timeseries'), __dir__)
Package Dependencies
It is common for packages to depend on other packages.
When adding a dependency to a Ruby package, you must add it to the
package's manifest.xml file. If you do mean to distribute your Ruby package
as a RubyGem, you will also have to modify the bundler-generated gemspec
file.
Tests
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 flexmock.
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.