From: <gr...@us...> - 2003-05-26 08:11:46
|
in frontend.py read_config_file could be changed to:: default_section = 'options' for section_name in config_parser.sections: if section_name == default_section: prefix = '' else: prefix = section_name + '_' settings = config_parser.get_section(section_name) make_paths_absolute(settings, parser.relative_path_settings, os.path.dirname(value)) parser.values.__dict__.update(settings) transaltes (untested) section:: [latex] stop=1 to settings.latex_stop=1. * And then again maybe not, the function is not called ? * And do we need to specify latex_stop and stop options in the setting_spec ? -- BINGO: collaboratively initiate competitive deliverables --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: David G. <go...@py...> - 2003-05-27 13:50:53
|
I didn't get around to replying to this yesterday, sorry. But Engelbert, you committed the change to CVS prematurely. gr...@us... wrote: > in frontend.py read_config_file could be changed to:: > > default_section = 'options' > for section_name in config_parser.sections: Missing "()" before ":". This caused the cron job to crash. Please test before committing. If you don't understand what code is for or don't know how to test it, don't commit! That's what the SourceForge patch manager is for. > if section_name == default_section: > prefix = '' > else: > prefix = section_name + '_' > settings = config_parser.get_section(section_name) > make_paths_absolute(settings, parser.relative_path_settings, > os.path.dirname(value)) > parser.values.__dict__.update(settings) > > transaltes (untested) section:: > > [latex] > stop=1 > > to settings.latex_stop=1. No, it doesn't. The "prefix" local is not used for anything. > * And then again maybe not, the function is not called ? That function is only called when the --config option is used on the command line. Changing it won't help with default config files. > * And do we need to specify latex_stop and stop options in > the setting_spec ? Using that scheme, yes. I'm not comfortable with this change: it has bugs and is incomplete (doesn't apply universally). Even if it ran properly and was complete, it's a far-reaching change that will affect all of Docutils. It's too early for this. I reverted the code. -- David Goodger |
From: <gr...@us...> - 2003-05-27 15:25:33
|
On Tue, 27 May 2003, David Goodger wrote: > I didn't get around to replying to this yesterday, sorry. But > Engelbert, you committed the change to CVS prematurely. sorry slipped through i did not mean to change this. seam to have not reverted completely. > > * And then again maybe not, the function is not called ? > > That function is only called when the --config option is used on the > command line. Changing it won't help with default config files. > > > * And do we need to specify latex_stop and stop options in > > the setting_spec ? > > Using that scheme, yes. I'm not comfortable with this change: it has > bugs and is incomplete (doesn't apply universally). Even if it ran > properly and was complete, it's a far-reaching change that will affect > all of Docutils. It's too early for this. I reverted the code. should not be far reaching. if we allow prefixed and nonprefixed options, nothing would change. this might be desireable as: calling publisher with a latex writer maybe --stop and --latex-stop should be made to work ? OTOH every publish has * a reader(with options) * a parser(with options) * a writer(with options) we might need a resource db: options to any writer, reader, ... and some only to specific writers. my problem was (as you sure recognized) how to test this with changing options, and as i have with other projects, testing permutations of config files. and where to patch so it is used all the time. and i vote for doing it sooner than later, as the configuration fills up. -- BINGO: Sind Sie flexibel? --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: David G. <go...@py...> - 2003-05-27 21:00:34
|
gr...@us... wrote: > seam to have not reverted completely. I didn't actually "remove the revision" revert, just "return to old revision's code" revert. Revision 1.30 now contains the same code as 1.28; 1.29 still has a record of the change. See <http://cvs.sf.net/cgi-bin/viewcvs.cgi/docutils/docutils/docutils/frontend.py.diff?r1=1.28&r2=1.30>. >> it's a far-reaching change that will affect >> all of Docutils. It's too early for this. > > should not be far reaching. But it will be. It sets a standard for the future, and should be well thought-out. Does the proposed solution handle all current and forseeable cases? I don't understand the intention or the specifics well enough yet to be comfortable with the direction of the change. Perhaps write it up in a To-Do list entry? There's already this: Perhaps we need to re-evaluate the config file format, possibly enabling a section for each Docutils component so that (for example) HTML's and LaTeX's stylesheets don't interfere with each other. Please add detailed examples, to the to-do list or here on the mailing list. How would the new config file entries relate to command-line options? The command-line has no concept of "sections". > if we allow prefixed and nonprefixed options, nothing would change. > this might be desireable as: calling publisher with a latex writer > maybe --stop and --latex-stop should be made to work ? I don't understand. Please explain with specifics. What is "--stop" supposed to do? > OTOH every publish has > > * a reader(with options) > * a parser(with options) > * a writer(with options) There are also the Docutils-general settings, defined in docutils.frontend.OptionParser. > we might need a resource db: options to any writer, reader, ... > and some only to specific writers. Perhaps. Let's explore that. Which ones? Where? Perhaps a dictionary in docutils.SettingsSpec (in docutils/__init__.py) would be a good place for these, since it's the ancestor of all settings-specifying components. Perhaps not. There are already "stylesheet" options for the HTML, PEP-HTML, and LaTeX writers. That would be a good example to explore. > my problem was (as you sure recognized) how to test this with > changing options, and as i have with other projects, testing > permutations of config files. > > and where to patch so it is used all the time. That would be in docutils.frontend.ConfigParser. > and i vote for doing it sooner than later, as the configuration > fills up. Better to keep the current kludge than add another prematurely. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |
From: <gr...@us...> - 2003-05-28 08:09:26
|
On Tue, 27 May 2003, David Goodger wrote: > >> it's a far-reaching change that will affect > >> all of Docutils. It's too early for this. > > > > should not be far reaching. > > But it will be. It sets a standard for the future, and should be well > thought-out. Does the proposed solution handle all current and > forseeable cases? I don't understand the intention or the specifics > well enough yet to be comfortable with the direction of the change. > Perhaps write it up in a To-Do list entry? There's already this: > > Perhaps we need to re-evaluate the config file format, possibly > enabling a section for each Docutils component so that (for example) > HTML's and LaTeX's stylesheets don't interfere with each other. > > Please add detailed examples, to the to-do list or here on the mailing > list. How would the new config file entries relate to command-line > options? The command-line has no concept of "sections". > > > if we allow prefixed and nonprefixed options, nothing would change. > > this might be desireable as: calling publisher with a latex writer > > maybe --stop and --latex-stop should be made to work ? > > I don't understand. Please explain with specifics. What is "--stop" > supposed to do? nothing, take --stylesheet. > > OTOH every publish has > > > > * a reader(with options) > > * a parser(with options) > > * a writer(with options) > > There are also the Docutils-general settings, defined in > docutils.frontend.OptionParser. > > > we might need a resource db: options to any writer, reader, ... > > and some only to specific writers. > > Perhaps. Let's explore that. Which ones? Where? Perhaps a > dictionary in docutils.SettingsSpec (in docutils/__init__.py) would be > a good place for these, since it's the ancestor of all > settings-specifying components. Perhaps not. > > There are already "stylesheet" options for the HTML, PEP-HTML, and > LaTeX writers. That would be a good example to explore. it does no harm when the stylesheet switch is applied on the commandline, but obviously does not work in a configuration file. so we must add sections to the configuration file. ini-style --------- :: [option] stylesheet=default.css [html] stylesheet=my.css [latex] stylesheet=mystyle.tex sets a. :: settings.stylesheet settings.html_stylesheet settings.latex_stylesheet b. :: settings.stylesheet settings.html[stylesheet] settings.latex[stylesheet] version b. would make a general getter function easier:: get_setting(setting_name='stylesheet',prefer='latex') i donot see any kludgeness here. resource db ----------- has more possibilities, but i donot think we need it and handling is more complicated. for example:: writer.*.stylesheet=default.css *.errorColor=red and there is a difference between *ErrorColor and *errorColor. kludges ======= 1. i dislike having --latex-stylesheet and --stylesheet in the writers option list. should be handled in a generic way. 2. stylesheet is an option to components that never are used concurrently, but what if an option for a frontend has the same name as for a writer. then we need the prefix. > > and i vote for doing it sooner than later, as the configuration > > fills up. > > Better to keep the current kludge than add another prematurely. i see some danger in filling up the option name space and having to change this afterwards. -- BINGO: Ich komme auf Sie zu --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+ |
From: David G. <go...@py...> - 2003-05-28 19:18:25
|
[Engelbert Gruber] > so we must add sections to the configuration file. > > ini-style > --------- > > :: > > [option] > stylesheet=default.css > [html] > stylesheet=my.css > [latex] > stylesheet=mystyle.tex If we have [html] and [latex] sections, "stylesheet" should probably not exist in [options]. If we do implement config file sections, I think [options] should be replaced by [general]. > sets > > a. :: > > settings.stylesheet > settings.html_stylesheet > settings.latex_stylesheet > > b. :: > > settings.stylesheet > settings.html[stylesheet] > settings.latex[stylesheet] That (b) is dangerous, because a section name would clobber a general setting of the same name. A general setting would have to be ``settings.general['stylesheet']``. Dictionary keys have to be quoted, too (``settings.html['stylesheet']``). ``settings`` could be a multi-level dotted-name-access object, thus ``settings.html.stylesheet``. Either approach would require some patching of docutils.frontend.OptionParser and ConfigParser. Also, there has to be a very clear one-to-one relationship between config file entries and command-line options. > resource db > ----------- > > has more possibilities, but i donot think we need it and > handling is more complicated. > > for example:: > > writer.*.stylesheet=default.css > *.errorColor=red > > and there is a difference between *ErrorColor and *errorColor. I don't follow this at all. Please elaborate. What specifically do you mean by a "resource db"? > kludges > ======= > > 1. i dislike having --latex-stylesheet and --stylesheet in the > writers option list. should be handled in a generic way. Huh? "--latex-stylesheet" doesn't exist. Do you mean to say "I *would* dislike having ..."? IOW prefixes shouldn't migrate to command-line option names? > 2. stylesheet is an option to components that never are used > concurrently, but what if an option for a frontend has the > same name as for a writer. then we need the prefix. Or we just avoid duplicate names where incompatible, as now. > i see some danger in filling up the option name space and having > to change this afterwards. The problem is already there. The namespace is already full enough that a few more settings won't matter much. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |