Log file Viewer
#buildout logs for Saturday the 26th of January, 2013
[10:35:08] <pombreda_> http://www.buildout.org/ site is really out of date, what could we do about it?
[16:05:20] <pombreda_> del buildout['section name'] is not implemented and del buildout._raw['section name'] does not do what I would need ... whic would the equivalent of parts -= <section name>
[16:14:46] <pombreda_> J1m: roger that, I am hacking some test stuffs for doing conditional sections... section that get removed if they have a skip_if python expression that evals to True
[16:16:28] <J1m> If you're just hacking, hack on a fork of buildout itself. Rather that deleting sections, filter them when they're being gathered. This is something I'd be open to as a pull request.
[16:19:15] <pombreda_> J1m: ok, the filtering condition would at first be a python expression with no locals, no globals and no builtins... then relaxing this later
[16:21:10] <pombreda_> J1m: buildout itself does not reserve the use of any options names except when in the buildout section, right?
[16:22:18] <J1m> There are a 2 option names that buildout uses, "recipe", "_buildout_section_name_".
[16:23:33] <J1m> Note that in buildout 2, there are many more restrictions on option and section names.
[16:26:04] <pombreda_> J1m: I would care if a design would be to add the expression as a section option, rather than in the section title. but if you prefer add this in the title that is a non issue
[16:27:56] <J1m> The first Python version of buildout, used internally at ZC had platform tags in section heafers {mysection:win32]. This was very helpful for project built on both linux and windows.
[16:29:41] <pombreda_> J1m: on the dev side, I have varying eggs and parts needed for mac/linux/windows
[16:30:02] <pombreda_> J1m: on the prod side, the requirements are also quite different depending on OS
[16:30:09] <J1m> I expect we'd have some well considers predefined booleans, like win32, python2, python3, etc.
[16:31:23] <pombreda_> J1m: for predefined booleans, this provides a decent basis: https://github.com/kennethreitz/its.py/blob/master/its.py
[16:37:16] <J1m> who cares? This isn't a long running process and if you accept buildout configs from untrusted sources, you probably have bigger problems.
[16:37:58] <pombreda_> J1m: indeed, .... so one design approach would: do not allow expressions to be defined in titles, that would be ugly... instead provide default booleans and additional expressions could defined in an expression option of [buildout]
[16:38:57] <J1m> yeah. I think expressions are the way to go and default booleans make the common cases simple.
[16:39:37] <pombreda_> so [section:win32] would look for a either a predef boolean or if not found in an expression provided for instance in [buildout] condition-expression = win32 = 'win32' in sys.platform
[16:42:29] <pombreda_> J1m: agreed... now this could be handled in many places... the earlier the better... imhonin configparser.py
[16:43:30] <pombreda_> section_header = re.compile(r'\[\s*(?P<header>[^\s[\]:{}]+)\s*]\s*([#;].*)?$').match will need relaxing in anycase :P
[16:44:51] <pombreda_> J1m: the benefit is that in handling it early in the parser, the rest of the code could be left untouched
[16:44:59] <J1m> I think I would keep configparser simple and let it create tuple keys when there's an expression
[16:45:52] <J1m> I think it's buildout's concern to decide on the globals and thus the evaluation of the expressions.
[16:46:20] <J1m> It could easily apply the conditions at the point where it has constructed the raw data.
[17:06:13] <pombreda_> <J1m> "there are a number of good choke points." ==> which would be best then?
[17:07:28] <J1m> not sure. Let's go with your original idea and do it in configparser, but pass in a globals(/locals/namespace) dict.
[17:08:06] <J1m> so buildout decides what's available and configparser executes the expers and filters accordingly.
[17:08:49] <J1m> The globals should default to {} (meaning default to None, which is converted to an empty dict at run time)
[17:09:04] <pombreda_> I see three place where the configparser is called: _read_installed_part_options (does not make sense to have expression here), _open (which makes most sense) and _dir_hash which puzzles me
[17:16:01] <pombreda_> J1m: not sure what you mean about the default globals above, you mean in the function signature for configparser.parse ? chainging it from parse(fp, fpname) to parse(fp, fpname, globals=None)?
[17:19:56] <pombreda_> J1m: the syntax for the section title would become essentially the same as for an option except the separator would be header:expression instead of name=value
[17:29:01] <pombreda_> J1m: a regex for parsing the title would become ... \[\s*(?P<header>[^\s[\]:{}]+)\s*:?(?P<expression>.*)\s*]\s*([#;].*)?$ this would require a bit split in something easier to read :P
[17:32:07] <pombreda_> J1m: which BTW are great for testing but make for a rather odd documentation on the main pypi page
[17:33:04] <pombreda_> J1m: in general I am sure you reckon the doc is tad weak? we could get some Gsoc student to work on this?
[17:36:18] <pombreda_> J1m: UI used to be manage the program for the Eclipse foundation so i am somewhat familiar with it
[17:37:04] <pombreda_> actually the expression is .* so it globs spaces, but yes, regex are devilish without tests
[17:37:27] <J1m> buildut needs docs. I'm skeptical that a student could write them (or would want to).
[17:38:53] <J1m> I have no idea what you mean by "zope seems to have fewer interest in this after 2008 though"
[17:39:53] <pombreda_> J1m: zope as a foundation seems to have not participated in the Google Summer of code after 2008
[17:42:34] <pombreda_> J1m: about doc, the thing with buildout is that doctests are _not_ showing the way one actually _uses_ buildout... instead rather how it works when called from python, which is the least likely to happen in most use case
[17:43:45] <J1m> documentation should also be executable and can server as a subset of the tests, but it has to be designed as documentation.
[17:44:28] <pombreda_> I will not threaten of writing docs though atm ... but I guess if you would start with a simple 10 liners showing where you want to go pushing docs would be easier
[17:44:56] <pombreda_> J1m: and about doctest there is a badzillions of recipes that use the same approach you did and only have doctests as docs :P
[17:45:55] <J1m> There are lots of projects that have neither docs or tests. doctests are better than nothing. :)
[17:47:52] <J1m> There's a rather simple transformation that could be applied to the existing doctest that would make them much more readable and useful, even though the organization would still be wrong.
[17:48:12] <pombreda_> J1m: indeed ... the other projects may not have teh reach of it too... that said the only think that could come to mind for higher level docs as tests was fitnesse and may be roboframework nowadays though I have not used the later
[17:49:18] <J1m> then config files would be shown directly (without python "write" calls and system commands could be shown more naturally.
[17:50:04] <J1m> I need to update some of the tests to show the way and see if volunteers could do the others.
[17:51:01] <J1m> The configparser tests use manuel and they look much better than they would otherwise.