The goal of this project is to write a proof of concept of a new philosophy for yast2-storage-ng. Instead of just extending the API offered by libstorage-ng, the idea is wrap libstorage-ng so the Ruby code using yast2-storage-ng does not have direct visibility (unless explicitly desired) on the libstorage-ng classes and methods.
If you don't know what all that means, keep reading.
The YaST team is rewriting the storage stack (the part that manages disks, partitions, filesystems and so on). In the current implementation the low-level operations (partitioning and so on) are performed by a C++ library called libstorage. On top of that, yast2-storage provides an API for all the other YaST components and modules.
In the new implementation that should debut in SLE13, libstorage-ng already offers a higher level object oriented API with Ruby bindings (generated using SWIG). Although yast2-storage-ng is still there offering convenience classes and methods, now other YaST components directly use the classes provided by libstorage-ng to inspect the system and so on. So, contrary to the current implementation, yast2-storage-ng does not wrap libstorage-ng, but complements it by offering additional classes and refinements on top of the classes provided by libstorage-ng.
Now that libstorage-ng and yast2-storage-ng are quite feature-complete (although still far from the current versions) and used in several other YaST components, the direct use of libstorage-ng is starting to show some annoyances.
- Sometimes, the strict type-checking imposed by SWIG forces the Ruby code using the library to look clumsy (explicit type casting, a lot of calls to
#to_ain almost every collection coming from libstorage-ng, etc.).
- The structure of libstorage-ng is very flexible and, by design, it never hides that to the user of the API. Offering a method like
a_filesystem.diskwould go against the philosophy of the library. The user of the library is expected to do something like
a_filesystem.blk_devices.partition_table.partionable. That adds clarity about the real libstorage-ng structure, but does not ease the common case.
- The C++ take on object orientation sometimes differs from the Ruby one. We have discussed for very long time and in many threads about several aspects of the libstorage-ng API without reaching a clear consensus between the two "sides" of the team - the developers with a solid background in C++ vs the Ruby purists.
Fixing those problems by adding many refinements feels wrong (refinements are still second-class citizens in the Ruby world). On the other hand, YaST does not need access to every single class provided by libstorage-ng, at least not in a regular basis.
So let's see go back to the wrapping approach and see what happens. I already tried in the past and SWIG was too much in the way. But now I have new ideas.
Looking for mad skills in:
yast ruby c++
This project is part of:
Hack Week 15
This project is one of its kind!