On Tuesday 02 April 2002 10:41, Geoffrey Talvola wrote: > Tavis Rudd wrote: > > On Tuesday 02 April 2002 06:55, you wrote: > > > Now that 0.7 is out, I think it's high time that we moved > > > Webware in the direction of a 1.0 release. What things still > > > need to be done? > > > > In order of priority: > > > > - completely automated test suite, that is easy to add new tests > > to > > > > - distutils support, remove ability to run straight from the > > install dir, and remove need to run makeAppWorkingDir. > > What takes the place of MakeAppWorkDir if we switch to distutils? > (I know nothing about distutils.) We still have configuration > files, cache dirs, cgi scripts, etc. that MakeAppWorkDir sets up > for us, and that will presumably continue to be useful.
See Launcher.py in http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/expwebware/Webware/WebKit/ It is a major departure from the current load sequence in WebKit in which each class is responsible for finding its own config files. Instead it delegates all responsibility for finding and parsing config files to the Launcher class, which then proceeds to load the rest of the classes with the given config settings. However, each of the core classes inherits from SettingsManager (the same one used in Cheetah) so that they are capable of loading config files if they are used in a different context. The practical benefits are: - the setting up of webkit sandboxes for automated testing is much easier! - future refactoring, and local customizations, of the startup sequence is much easier, as the changes only need to be made in one place - SettingsManager works with an easier-to-read/write config file format 1. python setup.py install 2. create a config file called webkit.config **, specifying where the temp working dir is. 3. run 'webkit start' ** I think this file should be renamed webware.config > > - a semi-automated release cutting script, that 'cvs up's, > > updates version numbers, runs the automated test suite, presents > > the release manager with a summary of all the @@ comments in the > > source tree and a form to add the release notes, builds the docs > > and the release tarball, does a dummy install of the tarball and > > runs the test suite from it, commits the changes to the cvs and > > adds a new tag, uploads the tarball file to upload.sf.net, runs > > an automated https session to log the release manager into sf and > > post the new release, sends a release email to > > webware-discuss/webware-announce/comp.lang.python, and updates > > the vaults of parnassus. A goal could be for it should take no > > more than an hour to cut a beta release. > > That would be very nice. I'm a little worried about testing this > release-cutting script though -- I don't want it to go haywire and > start sending broken announcement emails, updating VoP with bad > data, etc. but how else do you test the script other than actually > doing a release? Also, the pages for updating SourceForge and VoP > may change over time, breaking the release script. Perhaps the > "risky" steps at the end of the release should remain manual. I was thinking of an interactive script or even a web interface that stops at critical points and displays the current state and asks for confirmation before proceeding. > > - documentation (formated in either xml-docbook or LaTeX) > > I don't know the pros and cons vs. our current use of simple HTML > with CSS. I definitely don't want to see it get any harder to > maintain the docs than it is now. This probably isn't going to > happen unless someone volunteers to do the conversion and maintain > the docs. And even then, I'm not sure Chuck will buy into it -- I > know the last time this was discussed he expressed a preference for > the current format :-) This should actually make it easier to maintain once the setup has been done. It will also allow output to multiple formats. > > - better handling of config settings: > > - refactored to use the wrapper pattern, in which each class is > > given its settings from the 'Launcher' wrapper instead of having > > to go and get them. > > - better config file syntax (pure python or the one used in > > WebwareExpRefactoring) > > I don't see the necessity for these changes -- I get by just fine > with the current config files. Perhaps it could be a bit more > flexible, but in practise I don't see how I would really benefit > from that flexibility. See above. > > - ability to provide local subclasses of core classes such as > > Application > > That would be great, but not IMHO necessary for 1.0. I agree, but it's easier enough to do. > > - a better logging framework: > > - separation of error reporting from error logging > > - based on either Sacha's LoggingKit or PEP 282 > > (http://python.sourceforge.net/peps/pep-0282.html) > > - ability for multiple Webkit process to write to the same log > > (syslog, NT event log, or something similar but Webware specific) > > Also not necessary for 1.0 IMHO. Python may grow its own logging > module soon -- I think there's a PEP and a reference implementation > already. So I'd rather wait and see if that makes it in. I agree, but that it's not essential, but it would be nice. > > > The only item I feel is essential is to write reasonably > > > complete automated tests. I'd like to be able to sync to the > > > tip of CVS and run a single command to fully test every Webware > > > component. > > > > I agree, this absolutely essential. See the automated testing > > framework in the experimental refactoring of Webware I've been > > working on > > (http://webware.colorstudy.net/twiki/bin/view/Webware/WebwareExpRef >actoring) . > > > The most difficult and labour intensive part of this is being > > able to auto-load, run, and shutdown a WebKit process. This > > requires a builtin http server and a simple mechanism for > > controlling the config settings. I refactored the configuration > > mechanism and made it so all settings can be fed into the process > > via a pickled dictionary. For testing, this is way simpler than > > having to write each config file separately. > > It doesn't require a builtin http server if we just require Apache > to be used for testing. We want to test the Apache adapters after > all... In that case you'd have to run the test suite as root. IMHO, it should be possible to just download the tarball, run python setup.py install, then 'webware test' and have all the details taken care of. However, I agree that there should be an automated test of the adaptors as well. > And writing out config files in the current form is easy. You can > suck in an existing config file using eval(), modify it, and spit > it out with repr() or pprint.pformat(). But you have to do those steps for each config file, handle the path relationships and manage the creation of an alternate config dir. This is all handled by a single method call in the test framework I've been working with: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/expwebware/Webware/WebKit/Test/Test.py?rev=1.13&content-type=text/vnd.viewcvs-markup Cheers Tavis _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
