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, <[email protected]>
Senior Software Engineer, Research & Development
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284
(AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
