GSoC 2014, Week #5: Midterm evals approaching

Hello,

     For everyone who hasn't done a Google Summer of Code or known anyone who has I'll explain a little bit about it shortly.

     For the past ten years, Google has offered a program worldwide that allows students the opportunity to get a stipend to write code for open source organizations. This is Google Summer of Code. In order to get in to the Summer of Code you need to supply a proposal which can consist of your project proposal and a time line that you expect to go by in order to break things into manageable pieces. If you get accepted you then begin your summer project!

    It doesn't mean everything is in the clear just because you were accepted though. Throughout the Summer of Code you have to go through two evaluations:

• The Midterm Evaluation (June 23rd)
• The Final Evaluation      (August 22nd)

Essentially, these are both evaluations from your project mentor that confirm you are keeping up with your proposed time line. If you do not pass either of these, you don't get to fully finish the Summer of Code. You will be removed and you will cry yourself to sleep thinking about what could've been! (Tragic, right?)

    Never fear though, not only am I keeping up with my proposed time line, but I'm actually ahead of schedule (I also hope to stay ahead of schedule).

This following week the following work has been done for layman:

1.) Minimal changes to documentation and code:

    This week's minimal changes include changes to the manual page formatting to make it a little cleaner when being displayed. As well as changes to the way both config.py and overlay.py handle dictionary logic.

    For those of you who have never coded in python allow me to briefly explain what a dictionary is:

    A python dictionary is a data structure that associates a value with a key, not uncommon to that of an actual dictionary. To grab a value from a dictionary in python you can do a few things, but the most common way of grabbing a specific value from a dictionary is by simply grabbing its value as so:

    dictionary['<key>']

    With that slight crash course on python dictionaries allow me to explain the problem with layman's previous dictionary logic: In some cases layman's code would check dictionaries for values by doing something like this -

        if dictionary['key']:
            ....

    This logic has been tested by me in both py2.7 and py3.x and neither times would anything like this actually end up with anything other than KeyError: 'value' if the value wasn't in the dictionary. Part of me believes that this logic might have worked in previous versions of python but I haven't tested it to confirm. My implemented solution was to change the logic to something like this:

        if 'value' in dictionary:
            ....

This will prevent the code from causing runtime errors and will neatly check to see if the value exists in the keys of the dictionary.

2.) Beginning addition of layman portage sync plugin module:

    Going on the idea that if you're using layman then the chances of you using Gentoo are extremely high. Furthermore, the chances of you using portage is just as high, if not higher.

    In my previous posts I explained how to add a layman overlay, but did I ever mention how to sync the overlay? If I did, then...oh well. Under the assumption that I never explained how to sync layman overlays I will explain now. You can either sync all the installed overlays with the command: layman -S or you can sync an individual overlay with the command: layman -s <overlay>. Simple, no?

    This doesn't take into account that you also sync your main portage overlay via emerge though. So when you want to sync secondary overlays you'll have to do sync them via layman and then your main via emerge. If you're anything like me you sync portage very often and regularly forget to sync your layman overlays. So throughout this week I've been in the process of doing two things, the first of which is working on adding a portage sync plugin module for layman.

How this is done:

    Although the current version of portage does not support sync modules, it is in the works to have a version of portage that does support sync modules. So that's why I'm making one for layman. So until that version of portage becomes available on the portage tree I'll lazily say you don't need to know how I added the module. However, I will explain slightly how I created the module itself.

    You need two things:

• The __init__.py
• The module.

    In the __init__.py you need to specify the config_class and the module specifications. To see both, you can look at my source code to get a better look, this part isn't complicated. Even for someone who has never coded before.

    In the module you need to create your config class and have it subclass the SyncBase class. From there you need to specify your __init__() function, your new() function, and your _sync() function. That is the bare minimum requirements for a portage sync plugin.

The layman sync plugin uses two different methods to be ran:

1. Subprocess method
2. API method

Firstly, we'll discuss the more common and simplistic of the two, the subprocess method. Portage already has a built in function to execute processes and this is call the portage.process.spawn_bash() function. This function will also return an exit code upon completion of the process. It's really quite beautiful.

For a user to add a sync plugin it'd be as simple as adding the execution of the subprocess for portage to execute.

Secondly, we'll discuss the API method of the layman sync plugin module. This method is slightly more complex than the previous one but is considerably less complex than some other things.

To make use of layman's API and not require a subproccess to be executed, we added this second config_class. This class creates an instance of layman's API and executes it's built-in sync function directly. Multiple checks have been added to ensure the API will be instantiated when necessary in order to become less resource intensive. Why is that?

Well, consider you have 5 overlays installed on your system. Okay, 5 isn't that many. But if you have portage syncing your layman overlays and say you have 50 overlays instead of 5, it would have to create an instance of the layman API 50 times when it might not be necessary.

3.) Overlay definition generator script in the works:

    If you were to look into layman's manual you would see that you can actually create your own overlay definitions in one or many .xml files and layman will pick them up if they are in the correct directory (default is: /etc/layman/overlays, but can be changed via command line or config setting. Multiple examples are also included in the overlay to guide users into making their own overlay.xml definitions.

    For the ease of use for users and developers both, a tool is being created that allows you create an overlay definition via a script that can be ran in the safety and comfort of your terminals.

4.) A note to all Gentoo users:

    This week we also released a test version of layman into the wild for users to hunt bugs with. So for any brave soul that is willing to test this and report back feedback of any kind, it'd be greatly appreciated.

    To install it on your system, simply install the -9999 version of layman in the portage tree and enjoy! Don't be afraid, it shouldn't bite you.

Goals for next week:

• Revamp the overlay definition generator script.
• Polish up the portage sync module.
• Begin adding squashfs overlay support.

As always, to anyone interested the source code and my commits can be found on git.overlays.gentoo.org/gitweb/[1][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
  [1][1] Because my main computer has been down I haven't been able to push
            my latest commits to this repo.
  [2]https://github.com/twitch153/layman/tree/gsoc2014