On Thu, Feb 23, 2017 at 05:45:48PM +0100, Ancor Gonzalez Sosa wrote:
My Hack Week project is in that state in which all the important parts work and now it's time to decide if it's worth investing a couple of extra days to finish it all the way down.
Since the ultimate goal is to change how YaST interacts with storage-ng, I would need the opinion of as many YaST developers as possible.
So please, please, please, take a look to this and give your opinion. https://github.com/yast/yast-storage-ng/pull/169
Some examples using the swig bindings directly can be better, e.g.: puts "Ptable type #{a_storage_msdos_ptable.type}" #=> Prints "Ptable type 1" puts "Ptable type #{a_storage_msdos_ptable.to_s" or puts "extended" if [Storage::FsType_EXT2, Storage::FsType_EXT3, Storage::FsType_EXT4].include?(a_storage_filesystem) puts "extended" if Storage.ext?(a_storage_filesystem) Ok, ext? is new (part of my hackweed project). So far ext2 and ext3 were not implemented. ptable.type == Storage::PtType_GPT Storage.gpt?(ptable) Concerning the nil instead of exceptions: a_y2storage_unused_partition.filesystem #=> nil What happens here (nilclass exception?)? a_y2storage_unused_partition.filesystem.mount_by? I also thought about placing some classes in sub-namespaces but mainly to resolve the upcoming name collision of DASD (the "disk") and DASD (the partition table).
The most important question is - do you prefer the proposed approach and API* or do you prefer to continue accessing directly to libstorage-ng from YaST?
For me it will make programming in Ruby more difficult since I
have to know two APIs (already mentioned in doc/design-decisions.md).
ciao Arvin
--
Arvin Schnell,