Fwd: Goals for next weeks

[Eugenio Cano-Manuel Mendoza]

Last week we discussed some issues regarding the project. As you already
know from my weekly report last week I took care of most of it as well,
still some things here and there but I'm happy with it. Today I decided to
take another approach regarding options and 'properties' of the project,
something different from the Project class that we currently have and
closer to what Wolodja was talking about (I think). I'm going to introduce
what we had before and what we have now:

The goal is just to have a dictionary full of variables that will represent
the context to be rendered with jinja templates. Each of these variables
can come from different sources such as the environment, a command line
option, the name from project.clj... The list of different variables and
where they come from is on [1]

Prior to today, all these different sources were being treated in three
different classes: OptionParser, PropertyParser, and Project. Command-line
options, environment variables, and configuration files are processed in
OptionParser, for each of these three (cmdline, env, conf file) a
dictionary was retrieved and the idea was using the dict.update method one
after the other in order to represent priority (and merging), this big
dictionary was then used to create a Project instance. The Project instance
itself was more or less like a dictionary with the variables needed to
create a context for jinja, these variables were created using a set of
rules represented by methods, each method defines how a variable is
constructed. see [1] for each of the rules. To summarize: The options were
being treated in OptionParser, the variables created on Project.

Today I tried to make everything more explicit to the point where there's
no OptionParser or Project class. I created a set of functions that simply
return what we want:

def generate_template_variables(prop, cmdline, env, conf):

    prop = wrap_get(prop, '')
    cmdline = wrap_get(cmdline, '')
    env = wrap_get(env, '')
    conf = wrap_get(conf, '')

    return {
        'source_name': _get_source_name(prop, cmdline, env, conf),
        'package_name': _get_package_name(prop, cmdline, env, conf),
        'version': _get_version(prop, cmdline, env, conf),
        'description': _get_description(prop, cmdline, env, conf),
        'itp_bug': _get_itp_bug(prop, cmdline, env, conf),
        'homepage': _get_homepage(prop, cmdline, env, conf),
        'dependencies': _get_dependencies(prop, cmdline, env, conf),
        'genfiles': _get_genfiles(prop, cmdline, env, conf),
        'fullpath_deps': _get_fullpath_deps(prop, cmdline, env, conf),
        'use_javahelper': _get_use_javahelper(prop, cmdline, env, conf),
        'maintainer_name': _get_maintainer_name(prop, cmdline, env, conf),
        'maintainer_email': _get_maintainer_email(prop, cmdline, env, conf)
    }

where prop, cmdline, env, conf are dictionaries. Prop representing what was
found in project.clj or pom.xml, cmdline the command-line options, env is
the environment variables and conf is the variables found in the
configuration files.

Each of the functions look like this:
def _get_maintainer_email(prop, cmdline, env, conf):

    return first_of([
        cmdline('email'),
        env('DEBEMAIL'),
        conf('email')
    ])

Clearly reflecting what was on the table[1] (that was the goal anyways).
Please take a look at leinpkg/debtemplate.py for more info.

I personally think this is simpler and more flexible than having the 3
classes there (now is just PropertyParser and this
generate_template_variables function). I created 2 tests and noticed I
achieved the same functionality in less lines.

So my question to you is if you like this better than the old approach or
how can I improve this one? Wolodja: Is this what you were talking about
about being more explicit?

Cheers,
PS: The name of the funcions and the files might change, I don't like them.
PS2: If you have any questions about what happened last week let me know
(exceptions, new style classes, refactoring...)


[1]http://titanpad.com/OGcNayAacG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-clojure-maintainers/attachments/20130722/4f96ea35/attachment.html>