<div dir="ltr">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:<div>
<br></div><div style>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]</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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:</div><div style>
<br></div><div style><div>def generate_template_variables(prop, cmdline, env, conf):</div><div><br></div><div>    prop = wrap_get(prop, '')</div><div>    cmdline = wrap_get(cmdline, '')</div><div>    env = wrap_get(env, '')</div>
<div>    conf = wrap_get(conf, '')</div><div><br></div><div>    return {</div><div>        'source_name': _get_source_name(prop, cmdline, env, conf),</div><div>        'package_name': _get_package_name(prop, cmdline, env, conf),</div>
<div>        'version': _get_version(prop, cmdline, env, conf),</div><div>        'description': _get_description(prop, cmdline, env, conf),</div><div>        'itp_bug': _get_itp_bug(prop, cmdline, env, conf),</div>
<div>        'homepage': _get_homepage(prop, cmdline, env, conf),</div><div>        'dependencies': _get_dependencies(prop, cmdline, env, conf),</div><div>        'genfiles': _get_genfiles(prop, cmdline, env, conf),</div>
<div>        'fullpath_deps': _get_fullpath_deps(prop, cmdline, env, conf),</div><div>        'use_javahelper': _get_use_javahelper(prop, cmdline, env, conf),</div><div>        'maintainer_name': _get_maintainer_name(prop, cmdline, env, conf),</div>
<div>        'maintainer_email': _get_maintainer_email(prop, cmdline, env, conf)</div><div>    }</div><div><br></div><div style>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.</div>
<div style><br></div><div style>Each of the functions look like this:</div><div style><div>def _get_maintainer_email(prop, cmdline, env, conf):</div><div><br></div><div>    return first_of([</div><div>        cmdline('email'),</div>
<div>        env('DEBEMAIL'),</div><div>        conf('email')</div><div>    ])</div><div><br></div><div style>Clearly reflecting what was on the table[1] (that was the goal anyways). Please take a look at leinpkg/debtemplate.py for more info.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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?</div><div style>
<br></div><div style>Cheers,<br>PS: The name of the funcions and the files might change, I don't like them.<br>PS2: If you have any questions about what happened last week let me know (exceptions, new style classes, refactoring...)</div>
</div></div><div style><br></div><div style><br></div><div style>[1]<a href="http://titanpad.com/OGcNayAacG">http://titanpad.com/OGcNayAacG</a></div><div><div><br></div></div></div>