GSoC 2014, Week #11: Code Refinement at its finest

Hello again everyone,

This week was a fairly busy week due to my birthday and all the celebration that revolved around that.

Don't worry though! I didn't completely slack off. Work was accomplished.

1.) Modular overlay type plug-ins:

    If you can recall from my previous posts, I explained a little about the SquashFS overlay type as well as making the code for both Tar and SquashFS overlay types common in one class called ArchiveOverlay. If any of that doesn't sound familiar, no worries. I'll explain as we go along. But knowing of that will help you understand a bit better of what I'm about to discuss.

    This week I implemented a system in layman that will interact with modules. This commit: https://github.com/twitch153/layman/commit/0d4523513464c9bce836308d085995cb8a24644b is the module plug-in system and essentially what it does is look in a specified directory and find all available plug-ins. From there it will become a container of sorts that will obtain the class of any module, by name.

    This logic was then implemented into layman's overlay types. Recall wanting to install the overlay "twitch153". You would invoke layman as so: layman -a twitch153 and it would install (as long as you have git installed on your system). So you need to have git on your system and layman just magically takes care of it! Vioala!

    Well, in reality, you need git on your system because layman is informed that the type of the overlay is "git". The Overlay class will then find the proper class associated with "git", which in turn would be "GitOverlay". From there it would go to that class' add() function to see what steps would be necessary to add the overlay.

    As always, we strive to know more about why things happen. So why oh why am I explaining this to you and wasting the precious time you could be spending looking at lolcats and looking at other people's pictures of their food on their Facebook? Simple. Now that the module plug-in system has been implemented the Overlay class no longer needs to keep track of the available overlay type classes. This makes the main code much more maintainable, as well as making the addition of a new overlay type (such as squashfs) as simple as adding it to the correct directory and configuring it correctly.

    This also has another benefit to it. If this gets implemented into the main version of layman (which I would hope it does), it would make it possible to split out the modules into their own separate packages. This follows the Gentoo mentality of having choice. In previous versions of layman (even the current 2.1.0), you have specific USE flags that determine which VCSs you would add support for in layman. So if you were to install layman with USE='-darcs' you would not emerge the darcs version control system as a dependency. You would, however still have the code in layman that handles darcs overlays.

    This goes against the mentality of choice and forces users to have something on their system that they might never use. This is why the nature of modular overlay-type plug-ins is a great thing.

That's all that was accomplished this week. I do hope to work a little more next week to try to pick up some of the slack I left behind because of my birthday. But hey, if you can't celebrate your own birthday then I feel bad for you.

Goals for next week:

•  Work on anything I need to in order to get the overlay-maker and the sync-plugin into the master branch of layman.
• Discuss splitting the layman overlay-type plug-ins.
• Refine layman's codebase.

As always, to anyone interested the source code and my commits can be found on git.overlays.gentoo.org/gitweb/[1] or on github.com[2] on layman's gsoc2014 branch.

  [1]http://git.overlays.gentoo.org/gitweb/?p=proj/layman.git;a=shortlog;h=refs/heads/gsoc2014
  [2]https://github.com/twitch153/layman/tree/gsoc2014

With regards,
    Devan Franchini (twitch153)