From: Tavis R. <ta...@ca...> - 2001-12-05 00:50:31
|
Well, better late than never ... I've ticked off most of the major items on the WishList/TodoList and packaged them together as something I've titled Webware-0.7experimental. http://calrudd.com/Webware/Webware-0.7experimental.tar.gz NOTE: It only includes code that I have personally tested, so although the directory structures are there for UserKit, PSP, etc., I haven't included the source files for them yet. Cheetah is included. There's much more in the README, but here's a quick overview: Tick List ---------------- * It has a non-threaded and forking versions of the dispatcher that will allow such things as IDE-debugging of servlets/applications (Chuck's BIG wish) and profiling of servlets & WebKit. * It includes an automated and easy-to-use testing framework for WebKit and the beginnings of a test suite. It automatically builds up a WebKit sandbox environment and runs servlets in that environment. Install the package, then run 'webkit test -v' to run the tests. * It includes an integrated HTTPServer. It has been tested, thanks to the new testing framework. * It uses a new Webware Component and Setup framework that is based on distutils, and fits in with Chuck's philosophy of what Webware Components are. Run 'webkit helpdesk start' after installation and point your browser to http://localhost:8081/ to learn more. There's alot to this framework, and it's well worth reading up on if you're interested in making Webware fully extensible. It is ready to roll for creating a 'batteries-included' distribution of Webware. * Your applications are now completely separate from the files in the Webware directory. The makeAppWorkingDir script is no longer needed, its behaviour is the default. * The 'webkit' launcher script is much more powerful than the existing ones: * it is object-oriented and thus extensible, unlike the existing ones * the daemon mode works on platforms without fork() (i.e.Windows) * the config files can be in either .ini format or in pure Python. Thus, you can load from raw settings OR live objects assigned in the config file! * It has the beginnings of a builtin HelpDesk application that is an evolution of the builtin application that comes with WebKit 0.6. Its purpose is to provide a centralized interface to the documentation and examples installed with Webware components and user applications. run 'webkit helpdesk start' after installation. * It has extension cascading. (see the WishList) * It is easy to use local subclasses of major WebKit classes such (Ian added this to the WishList yesterday). As such, it supports flexible UrlDecoding!! * It has a Request.fieldMulti() method. * It's MultiPortServer framework provides the hooks to implement WebDav and other protocols. * Geoff's 'ScalabilityEnhancments' suggestions from yesterday have been implemented on the WebKit side. * It has the necessary flexibility to implement gzip compression and OutputCaching. * It gives a more informative error message when someone points there browser direcly at the AppServer on port 8086. (Mike's Wish) * It uses SpacesNotTabs ;-) Changes Likely To Be Controversial ------------------------------------ * MiscUtils and WebUtils have been merged into a Python package called Webware.Utils. The 'Webware' package contains all the core classes and utitilities that are shared between Webware Components. WebKit, UserKit etc. are all in separate packages. If this causes a problem for people we can easily implement transitional versions MiscUtils and WebUtils that act as proxies to this new package. * It requires Python 2.0 and up. I don't see any compelling reason to continue support for 1.5.2. If people can install Webware they can also install 2.0! If they're concerned about breaking existing Apps by making that change, why don't they go through their Apps and make the few minor changes that might be required. * Some of the methods in the Request class that I complained about in reference to UrlDecoding and assuming too much about how UrlDecoding works have not been implemented as part of the core. If there is a need we can handle this via subclasses. ------------- I'm not submitting this as patches against the Webware CVS because the internal architectural changes are profound. Applying these changes via patches would break the existing codebase and render it useless for weeks while a code audit is performed. That would just piss everyone off! So please think of this package as an experimental DEVEL_BRANCH to the Webware CVS. That's what I hope it will become (Chuck ;-). There are some implementation details that are radically different from the existing Webware, but I feel that it follows and builds on the design principles of Webware: * Modularity * Flexibility/Extensibility * Webware as a suite of layered components, rather than as a monolith. In my not so humble opinion it provides a solid base for the 0.7 coding. See the README for TODO notes. I await your thoughts... Cheers, Tavis |
From: Tavis R. <ta...@ca...> - 2001-12-06 22:24:42
|
Geoff, On Thursday 06 December 2001 06:32, Geoffrey Talvola wrote: > Tavis, > > I'm slowly taking a look at your redesign code. The first big > incompatibility I noticed is the configuration mechanism. My > concerns are: > > - For Windows users, it's much nicer to have a specific extension > associated with config files. I can associate the ".config" > extension with my favorite Python editor so that I can edit it just > by double-clicking it, then since a config file is also a valid > Python source file, I get good syntax coloring. With your redesign > code, I can't really do that because it's called ".webkit_config" > or ".webkit_config_annotated" which are very unix-centric naming > conventions. I wanted a scheme that was simple, but extensible and not tied to a particular directory structure. Hence my proposal for a single config file that follows the unix standard of using ~/.whatever for storing application settings in a users directory. However, I'm beginning to rethink that. If we are using pure Python code as the default config syntax it might make sense to have a file name that allows the config file to be imported as a normal Python module. That would rule out dot files. Furthermore, we need a scheme that handles settings for all Webware Components, not just WebKit. That's where Chuck's multifile layout makes more sense than my single file scheme. Though, I still prefer having a single file for WebKit itself. you wrote: > - Why force all settings into a single file? I actually liked the > fact that settings for different components live in different > files, although I suppose I wouldn't mind the _option_ of combining > them into a single file. In Python source format this could be > done with class syntax like this: > > class AppServer: > setting1 = 'foo' > setting2 = 'bar' > class HTTPServer: setting1 = 'qux' The best of both worlds - bloody good idea! This layout would make it possible to use a single file or multifile layout!! If we just make WebKit and all other Webware components """import webware_config""" to get their settings we can use a single 'webware_config.py' module or 'webware_config/' package. Both look the same to Python. WebKit would have settings in webware_config.WebKit, UserKit would have them in webware_config.UserKit, and so on. If we use the 'class whatever:' scheme you suggested, the settings for WebKit could be in the module webware_config.WebKit OR the class WebKit in the module webware_config. The settings for AppServer could be in the module webware_config.WebKit.AppServer or in the class AppServer inside the webware_config.WebKit module. And so on ... With Python 2.1 and above, we could even use nested scopes to do things like: from __future__ import nested_scopes class WebKit: class AppServer: port = 8080 class HTTPServer: serverString = 'WebKit HTTP Server' class ApplicationDefaults: usePrivateSessions = 0 sessionIDToken = '_WEBKIT_SID_' class MyApp(ApplicationDefaults): someOtherSetting = 'foo' class MyOtherApp(ApplicationDefaults): someOtherSetting = 'bar' We'd need to provide an interface to get at the settings as the import statements wouldn't always work as expected, but that's no big deal. The keyword 'class' might be a bit misleading as we're not promissing 1-to-1 mappings to actual classes, but that's no big deal either. In fact, we can use anything that supports __getatrr__ and __setattr__ for the settings containers: modules, classes, objects, etc. This is much cleaner than dictionaries! One of the key features of the 'webkit' launcher script is that it can be launched from any directory and will find the appropriate config file, or use the one specified as an argument to the command. This proposal wouldn't affect the latter case, but if we used pure python imports to get the settings we'd probably have to do some temporary sys.path manipulation to make sure the correct 'webware_config' is imported in the former. The current search order for config files is ['.webkit_config', os.path.join(os.path.expanduser('~'), '.webkit_config'), '/etc/webkit_config' ] Your thoughts? Tavis |
From: Tavis R. <ta...@ca...> - 2001-12-06 23:07:35
|
On Thursday 06 December 2001 15:04, you wrote: > On Thu, Dec 06, 2001 at 03:34:29PM -0800, Tavis Rudd wrote: > > If we just make WebKit and all other Webware components > > """import webware_config""" to get their settings we can use a > > single 'webware_config.py' module or 'webware_config/' package. > > Both look the same to Python. WebKit would have settings in > > webware_config.WebKit, UserKit would have them in > > webware_config.UserKit, and so on. If we use the 'class > > whatever:' scheme you suggested, the settings for WebKit could be > > in the module webware_config.WebKit OR the class WebKit in the > > module > > webware_config. The settings for AppServer could be in > > the module webware_config.WebKit.AppServer or in the class > > AppServer inside the webware_config.WebKit module. And so on ... > As long as the config files are kept in separate directories from > the Webware modules. We want a directory structure that's split > according to "who maintains this file", and being able to update > Webware by simply unrolling a tarball. Of course. That's my major complaint about how it works at the moment. > > class WebKit: > > class AppServer: > > port = 8080 > If the Python parser accepts this. I like Python config files over > custom ones. Same here. Chuck and Geoff said the same. |
From: Geoffrey T. <gta...@na...> - 2001-12-06 23:40:05
|
At 03:34 PM 12/6/01 -0800, Tavis Rudd wrote: >you wrote: > > - Why force all settings into a single file? I actually liked the > > fact that settings for different components live in different > > files, although I suppose I wouldn't mind the _option_ of combining > > them into a single file. In Python source format this could be > > done with class syntax like this: > > > > class AppServer: > > setting1 = 'foo' > > setting2 = 'bar' > > > >class HTTPServer: > setting1 = 'qux' > >The best of both worlds - bloody good idea! This layout would make >it possible to use a single file or multifile layout!! > >If we just make WebKit and all other Webware components >"""import webware_config""" to get their settings we can use a single >'webware_config.py' module or 'webware_config/' package. Both look >the same to Python. WebKit would have settings in >webware_config.WebKit, UserKit would have them in >webware_config.UserKit, and so on. If we use the 'class whatever:' >scheme you suggested, the settings for WebKit could be in the module >webware_config.WebKit OR the class WebKit in the module >webware_config. The settings for AppServer could be in >the module webware_config.WebKit.AppServer or in the class AppServer >inside the webware_config.WebKit module. And so on ... I hadn't thought of doing config settings as a package, but that's definitely the cleanest way to have a directory full of config files, OR a single file. ... >The keyword 'class' might be a bit misleading as we're not promissing >1-to-1 mappings to actual classes, but that's no big deal either. In >fact, we can use anything that supports __getatrr__ and __setattr__ >for the settings containers: modules, classes, objects, etc. This is >much cleaner than dictionaries! I agree, I definitely prefer regular Python assignments over dictionaries. But it would be nice to allow both, if only to ease the transition. >One of the key features of the 'webkit' launcher script is that it >can be launched from any directory and will find the appropriate >config file, or use the one specified as an argument to the command. >This proposal wouldn't affect the latter case, but if we used pure >python imports to get the settings we'd probably have to do some >temporary sys.path manipulation to make sure the correct >'webware_config' is imported in the former. > >The current search order for config files is >['.webkit_config', >os.path.join(os.path.expanduser('~'), > '.webkit_config'), >'/etc/webkit_config' >] > >Your thoughts? I'm not sure I agree that it should search for the config file at all. Explicit is better than implicit, and in this case I think it's better to know exactly where your config settings are coming from, by specifying it right on the command line. You can always use a bash or .bat wrapper to avoid having to retype it every time. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Tavis R. <ta...@ca...> - 2001-12-07 00:19:29
|
On Thursday 06 December 2001 15:40, Geoffrey Talvola wrote: > At 03:34 PM 12/6/01 -0800, Tavis Rudd wrote: > >The keyword 'class' might be a bit misleading as we're not > > promissing 1-to-1 mappings to actual classes, but that's no big > > deal either. In fact, we can use anything that supports > > __getatrr__ and __setattr__ for the settings containers: modules, > > classes, objects, etc. This is much cleaner than dictionaries! > > I agree, I definitely prefer regular Python assignments over > dictionaries. But it would be nice to allow both, if only to ease > the transition. I've attached a copy of the old .webkit_config_annotated file translated to the proposed format. It seems to work with all versions of Python, not just 2.1 and up. This file contains all the settings and is more complicated than the average user will need so I've also attached an example of what typical config might look like. The SettingsContainer baseclass is used to make sure that settings that are in fact meant to be classes aren't handled as SettingsContainers. In practice a shorter name might be better. Finally, I've attached some simple functions that can be used to get settings out of the SettingsContainers recursively and turn them into dictionaries. > I'm not sure I agree that it should search for the config file at > all. Explicit is better than implicit, and in this case I think > it's better to know exactly where your config settings are coming > from, by specifying it right on the command line. You can always > use a bash or .bat wrapper to avoid having to retype it every time. Hmm, I agree, although it should be able to detect a webware_config module or package sitting in the dir that the script is called from. Ok, now back to that PSP stuff ;) Tavis |
From: Geoffrey T. <gta...@na...> - 2001-12-07 14:04:51
|
At 05:30 PM 12/6/01 -0800, Tavis Rudd wrote: >I've attached a copy of the old .webkit_config_annotated file >translated to the proposed format. It seems to work with all >versions of Python, not just 2.1 and up. This file contains all the >settings and is more complicated than the average user will need so >I've also attached an example of what typical config might look like. > >The SettingsContainer baseclass is used to make sure that settings >that are in fact meant to be classes aren't handled as >SettingsContainers. In practice a shorter name might be better. > >Finally, I've attached some simple functions that can be used to get >settings out of the SettingsContainers recursively and turn them into >dictionaries. I like it. I'd like it even better if there were some way to get rid of the SettingsContainer base class which seems to clutter it up a bit. Couldn't we just ignore any classes that start with underscores, and treat all other classes as setting containers? This would be consistent with Python's use of "from module import *" which ignores things that start with underscores. As far as naming conventions, these are valid Python modules/packages, so .py would probably be best. But it would be nice to be able to identify config files from their filename, so it could look like this for a multiple-file configuration: Configs/ __init__.py AppServerConfig.py ApplicationConfig.py ... or in a single-file format: WebKitConfigs.py In other words, things that contain multiple configurations end in "Configs.py" and things that contain single configurations end in "Config.py". The WebKit launcher would accept either a "Configs" directory, or a single-file "XXXConfigs.py" on the command-line, and would do the right thing. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Geoffrey T. <gta...@na...> - 2001-12-07 19:03:22
|
At 10:55 AM 12/7/01 -0800, Chuck Esterbrook wrote: >On Friday 07 December 2001 06:05 am, Geoffrey Talvola wrote: > > As far as naming conventions, these are valid Python > > modules/packages, so .py would probably be best. But it would be > > nice to be able to identify config files from their filename, so it > > could look like this for a multiple-file configuration: > > > > Configs/ > > __init__.py > > AppServerConfig.py > > ApplicationConfig.py > > ... > > >What's the __init__.py for? In other projects I just went with: > > >Configs/ > FooBar.config > > >and did an exec on FooBar to get the variables which looked like: > >reps = 50 >names = 'foo bar'.split() > >etc. The __init__.py was just so that the config files could be imported as a package. But if there are good reasons to stick with *.config, then obviously you can't just import the files as a package, so the reason for __init__.py goes away. >We definitely have to be able to distinguish the file as install.py >does things with config files (which will change in nature in the >future, but still be a requirement). > > >The plan I was changing for Configurable was simply to do an exec, >unless the first char was a {, in which case I would do an eval. Just make sure to chop off whitespace first. I don't know if you want to scan for comments before the first { or not. -- - Geoff Talvola gtalvola@NameConnector.com |
From: Chuck E. <Chu...@ya...> - 2001-12-07 19:46:17
|
On Friday 07 December 2001 11:04 am, Geoffrey Talvola wrote: > The __init__.py was just so that the config files could be imported > as a package. But if there are good reasons to stick with *.config, > then obviously you can't just import the files as a package, so the > reason for __init__.py goes away. The reason for .config is that install.py scans for *.config, although obviously it could scan for *Config.py and *Configs.py as well. But perhaps the real reason to axe __init__.py for config directories is for simplicity. I prefer fewer conventions-to-be-remembered when that doesn't force us to give up something important. > >We definitely have to be able to distinguish the file as install.py > >does things with config files (which will change in nature in the > >future, but still be a requirement). > > > > > >The plan I was changing for Configurable was simply to do an exec, > >unless the first char was a {, in which case I would do an eval. > > Just make sure to chop off whitespace first. I don't know if you > want to scan for comments before the first { or not. Agreed. I planned on making the assignment style the de facto style over dictionaries, so while some extra effort is nice, we don't have to be perfect. -Chuck |
From: Tavis R. <ta...@ca...> - 2001-12-07 19:40:21
|
On Friday 07 December 2001 11:26, Chuck Esterbrook wrote: > On Friday 07 December 2001 11:04 am, Geoffrey Talvola wrote: > > >The plan I was changing for Configurable was simply to do an > > > exec, unless the first char was a {, in which case I would do > > > an eval. > > > > Just make sure to chop off whitespace first. =A0I don't know if you > > want to scan for comments before the first { or not. > > Agreed. I planned on making the assignment style the de facto style > over dictionaries, so while some extra effort is nice, we don't > have to be perfect. Why not just go for only the assignment style and get rid of the old=20 dictionary parsing method completely? Transitioning an app from one=20 to the other is a matter of a few minutes. Keeping both around just=20 makes the code more complex and brittle. |
From: Chuck E. <Chu...@ya...> - 2001-12-07 20:11:37
|
On Friday 07 December 2001 12:49 pm, Tavis Rudd wrote: > Why not just go for only the assignment style and get rid of the old > dictionary parsing method completely? Transitioning an app from one > to the other is a matter of a few minutes. Keeping both around just > makes the code more complex and brittle. I don't think it's brittle or complex. The essence is: if s.strip()[0]=='{': dict = eval(s) else: dict = {} exec s in dict Even adding the comment detection would be easy. In general, I'm pro-backwards-compatible, particularly when it is this easy and convenient. You'll feel more like me when you have various paid-projects lying around and users with paid-projects who have been with you for more than a year. :-) I won't guarantee we'll always be backwards compatible, but we'll at least make a moderate effort. I place just as much importance on existing users as I do on cool new features. -Chuck |
From: Chuck E. <Chu...@ya...> - 2001-12-07 18:55:21
|
On Friday 07 December 2001 06:05 am, Geoffrey Talvola wrote: > As far as naming conventions, these are valid Python > modules/packages, so .py would probably be best. But it would be > nice to be able to identify config files from their filename, so it > could look like this for a multiple-file configuration: > > Configs/ > __init__.py > AppServerConfig.py > ApplicationConfig.py > ... What's the __init__.py for? In other projects I just went with: Configs/ FooBar.config and did an exec on FooBar to get the variables which looked like: reps = 50 names = 'foo bar'.split() etc. We definitely have to be able to distinguish the file as install.py does things with config files (which will change in nature in the future, but still be a requirement). The plan I was changing for Configurable was simply to do an exec, unless the first char was a {, in which case I would do an eval. -Chuck |
From: Tavis R. <ta...@ca...> - 2001-12-07 19:33:00
|
On Friday 07 December 2001 10:55, Chuck Esterbrook wrote: > On Friday 07 December 2001 06:05 am, Geoffrey Talvola wrote: > > As far as naming conventions, these are valid Python > > modules/packages, so .py would probably be best. =A0But it would be > > nice to be able to identify config files from their filename, so > > it could look like this for a multiple-file configuration: > > > > Configs/ > > =A0 =A0 =A0 =A0 =A0__init__.py > > =A0 =A0 =A0 =A0 =A0AppServerConfig.py > > =A0 =A0 =A0 =A0 =A0ApplicationConfig.py > > =A0 =A0 =A0 =A0 =A0... What I'm proposing something more like: 1) WebwareConfig.py OR 2)=20 WebwareConfig/ __init__.py WebKit.py UserKit.py MiddleKit.py OR 3) WebwareConfig/ __init__.py WebKit/ __init__.py AppServer.py ... UserKit.py MiddleKit.py The scheme we were talking about yesterday would allow the end user=20 to make the choice of whether to go for a single file or split it up.=20 To Webware and its components it would be transparent. I think=20 option 2 or 3 should be the default layout, as a Webware componenent=20 shouldn't meddle with another components configs. > What's the __init__.py for? In other projects I just went with: > Configs/ > FooBar.config > > > and did an exec on FooBar to get the variables which looked like: > > reps =3D 50 > names =3D 'foo bar'.split() The idea is to import the 'WebwareConfig' package so that all import=20 statements inside it will work properly without needing to manipulate=20 sys.path. Exec makes me go 'ick', when you could just to an import.=20 > We definitely have to be able to distinguish the file as install.py > does things with config files (which will change in nature in the > future, but still be a requirement). That brings up the issue of what should it be doing to the config=20 files? There have been fairly unanimous calls for the core classes=20 to be installed in a completely separate location from user files via=20 distutils. =20 But what about the config files? Do they also get installed to the=20 same place as the core packages or are they something the user must=20 install? I'd argue for installing a template of the configs to the=20 central location and then requiring the users to 'check out' a copy=20 they can modify locally ---> "<prompt> webware install-configs" or=20 something like that would copy the templates to the current directory=20 for the user to modify. =20 > The plan I was changing for Configurable was simply to do an exec, > unless the first char was a {, in which case I would do an eval. What do you think about the syntax that Geoff proposed as an=20 alternative to dictionaries? They're compatible, but I prefer the=20 class syntax. Tavis |
From: Chuck E. <Chu...@ya...> - 2001-12-07 21:44:25
|
On Friday 07 December 2001 12:43 pm, Tavis Rudd wrote: > The scheme we were talking about yesterday would allow the end user > to make the choice of whether to go for a single file or split it up. > To Webware and its components it would be transparent. I think > option 2 or 3 should be the default layout, as a Webware componenent > shouldn't meddle with another components configs. Then why bother with 1? For someone anxious to get rid of supporting dicts because it's extra cruft, it seems strange to put so much weight on the value of a monolithic config file. Particularly if it's not the default and not many people will use it. > > What's the __init__.py for? In other projects I just went with: > > Configs/ > > FooBar.config > > > > > > and did an exec on FooBar to get the variables which looked like: > > > > reps = 50 > > names = 'foo bar'.split() > > The idea is to import the 'WebwareConfig' package so that all import > statements inside it will work properly without needing to manipulate > sys.path. Exec makes me go 'ick', when you could just to an import. I wasn't imagining an import statement (other than os, sys, etc. for special situations) in a config file. In any case, I guess import over exec works just as well except for the __init__.py requirement. I'm 50/50 right now. > > We definitely have to be able to distinguish the file as install.py > > does things with config files (which will change in nature in the > > future, but still be a requirement). > > That brings up the issue of what should it be doing to the config > files? There have been fairly unanimous calls for the core classes > to be installed in a completely separate location from user files via > distutils. Right now it backs them up so you can refer to the original values. In the future, it will reverse that. eg., copy *.default.config to *.config for reasons that we discussed earlier. > But what about the config files? Do they also get installed to the > same place as the core packages or are they something the user must > install? I'd argue for installing a template of the configs to the > central location and then requiring the users to 'check out' a copy > they can modify locally ---> "<prompt> webware install-configs" or > something like that would copy the templates to the current directory > for the user to modify. I believe that MakeAppWorkDir, which was patched in by Robin Dunn, already does this today. I think it also takes advantage of *.config. Have you ever used it? > > The plan I was changing for Configurable was simply to do an exec, > > unless the first char was a {, in which case I would do an eval. > > What do you think about the syntax that Geoff proposed as an > alternative to dictionaries? They're compatible, but I prefer the > class syntax. I must have missed that message, so I don't know. In general, I strongly prefer Python over any custom config syntax. On Thursday 06 December 2001 03:34 pm, Tavis Rudd wrote: > We'd need to provide an interface to get at the settings as the > import statements wouldn't always work as expected, but that's no big > deal. Er, why? foo.bar.baz wouldn't work in your scenario? I like asking self for settings, btw. This allows classes and individual objects to partake in their configuration if needed. I have taken advantage of this when I needed to. BTW One issue with configuration is making the command line stuff come in correctly. eg, if you allow individual config settings to be passed on the command line like so: foo.py iters=50 Then iters comes in as a string instead of an int unless you go out of your way to do something about it. I handled this on one project by actual defining my config file settings: name, type, description, synonyms, etc. I used the description to generate docs. I used the type make sure things came in right from the command line and type check what was brought in via Python. Also, I find it just as important if not more so in my various projects to be able to tweak one setting on the command line, as I do to point to a whole new config file. Just more fuel for the fire, ;-) -Chuck |
From: Tavis R. <ta...@ca...> - 2001-12-07 22:00:51
|
On Friday 07 December 2001 13:34, Chuck Esterbrook wrote: > On Friday 07 December 2001 12:43 pm, Tavis Rudd wrote: > > The scheme we were talking about yesterday would allow the end > > user to make the choice of whether to go for a single file or > > split it up. To Webware and its components it would be > > transparent. I think option 2 or 3 should be the default layout, > > as a Webware componenent shouldn't meddle with another components > > configs. > > Then why bother with 1? For someone anxious to get rid of > supporting dicts because it's extra cruft, it seems strange to put > so much weight on the value of a monolithic config file. > Particularly if it's not the default and not many people will use > it. Ok, scrap 1 and point taking about my cruft fallacy. But the example was meant to illustrate that this scheme would use exactly the same logic to load settings from all of those layouts. > > > What's the __init__.py for? In other projects I just went with: > > > Configs/ > > > FooBar.config > > > > > > > > > and did an exec on FooBar to get the variables which looked > > > like: > > > > > > reps = 50 > > > names = 'foo bar'.split() > > > > The idea is to import the 'WebwareConfig' package so that all > > import statements inside it will work properly without needing to > > manipulate sys.path. Exec makes me go 'ick', when you could just > > to an import. > > I wasn't imagining an import statement (other than os, sys, etc. > for special situations) in a config file. In any case, I guess > import over exec works just as well except for the __init__.py > requirement. I'm 50/50 right now. > > > We definitely have to be able to distinguish the file as > > > install.py does things with config files (which will change in > > > nature in the future, but still be a requirement). > > > > That brings up the issue of what should it be doing to the config > > files? There have been fairly unanimous calls for the core > > classes to be installed in a completely separate location from > > user files via distutils. > > Right now it backs them up so you can refer to the original values. > In the future, it will reverse that. eg., copy *.default.config to > *.config for reasons that we discussed earlier. > > But what about the config files? Do they also get installed to > > the same place as the core packages or are they something the > > user must install? I'd argue for installing a template of the > > configs to the central location and then requiring the users to > > 'check out' a copy they can modify locally ---> "<prompt> > > webware install-configs" or something like that would copy the > > templates to the current directory for the user to modify. > > I believe that MakeAppWorkDir, which was patched in by Robin Dunn, > already does this today. I think it also takes advantage of > *.config. > > Have you ever used it? I've read the code and ran it once. The idea is the same, but I'd implement it a little differently to work well with the distutils framework. > > > The plan I was changing for Configurable was simply to do an > > > exec, unless the first char was a {, in which case I would do > > > an eval. > > > > What do you think about the syntax that Geoff proposed as an > > alternative to dictionaries? They're compatible, but I prefer > > the class syntax. > > I must have missed that message, so I don't know. > > In general, I strongly prefer Python over any custom config syntax. The syntax he proposed is pure Python. > On Thursday 06 December 2001 03:34 pm, Tavis Rudd wrote: > > We'd need to provide an interface to get at the settings as the > > import statements wouldn't always work as expected, but that's no > > big deal. > > Er, why? foo.bar.baz wouldn't work in your scenario? foo.bar.baz would work, but not necessarily "from foo.bar import baz" I was thinking more along the lines of: from WebwareConfig import getSettings theSettingsINeed = getSettings('WebKit.AppServer') That would accomodate having a single config file for WebKit or multiple files. > I like asking self for settings, btw. This allows classes and > individual objects to partake in their configuration if needed. I > have taken advantage of this when I needed to. I see your point, but think it's best not to bind classes to a particular scheme for finding configs on the file system. They should be able to do it when absolutely needed, but it shouldn't be part of their __init__ process. Doing so makes it harder to use them in situation beyond what the author intended. That's why I prefer the FacadePattern (http://c2.com/cgi/wiki?FacadePattern), in which you use a launcher class to collect the relevant settings and feed them to the various classes involved. It's more flexible. > BTW One issue with configuration is making the command line stuff > come in correctly. eg, if you allow individual config settings to > be passed on the command line like so: > > foo.py iters=50 Hmm, you could use SettingsManager for that. It can recognize strings that represent numbers (even complex nums) plus booleans(true/false) convert them to the appropriate Python value. You feed it a dictionary with string values and it will spit out a translated version of the dict. It also understands python literals like lists, etc. if you preface the string with "python: " foo.py iters=50 list="python: [1,2,3]" > Then iters comes in as a string instead of an int unless you go out > of your way to do something about it. I handled this on one project > by actual defining my config file settings: name, type, > description, synonyms, etc. I used the description to generate > docs. I used the type make sure things came in right from the > command line and type check what was brought in via Python. > Also, I find it just as important if not more so in my various > projects to be able to tweak one setting on the command line, as I > do to point to a whole new config file. Good point. Have a look at the new command line interface to Cheetah template modules that Mike and I added last night: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/cheetahtemplate/Cheetah/src/TemplateCmdLineIface.py?rev=1.4&content-type=text/vnd.viewcvs-markup It accepts os.environ or pickled objects as things to place at the beginning of the searchList and override $placeholder defaults. |
From: Chuck E. <Chu...@ya...> - 2001-12-07 21:24:20
|
On Friday 07 December 2001 06:05 am, Geoffrey Talvola wrote: > The WebKit launcher would accept either a "Configs" directory, or a We could also take the same route that Python and other apps follow when searching for files: - look in standard places - WebKit/Configs - ~.WebKit/Configs - look in an environment variable - CONFIGPATH=/etc/configs/webkit -Chuck |
From: Tavis R. <ta...@ca...> - 2001-12-07 21:37:03
|
On Friday 07 December 2001 13:15, Chuck Esterbrook wrote: > On Friday 07 December 2001 06:05 am, Geoffrey Talvola wrote: > > The WebKit launcher would accept either a "Configs" directory, or > > a > > We could also take the same route that Python and other apps follow > when searching for files: > > - look in standard places > - WebKit/Configs > - ~.WebKit/Configs > > - look in an environment variable > - CONFIGPATH=/etc/configs/webkit That's the approach I've taken in the experimental code up until now. It's doing it for a single config file, but the idea is the same. Look for ./webkit.config, ~/webkit.config, /etc/... But Geoff suggested that it might be better to require an explicit arg to the start script to make damn sure it doesn't get them from the wrong place. I don't think it's that likely. Nonetheless the launcher script should loudly declare where it is getting its settings from. Personally I like your suggestion of using an env var. If we went with a python package to contain the configs then you could use PYTHONPATH to locate them, unless WEBWAREPATH was set. ... something like that. The big question though is are we talking about 'WebKit' configs or 'Webware' configs??? There's a big distinction there. 'Webware' configs would allow us to deal with the settings for all Webware components in one place. I don't think the local settings for MiddleKit, UserKit, PieInTheSkyKit, etc. should be sitting in the WebKitConfigs directory. Do you? Tavis |
From: Chuck E. <Chu...@ya...> - 2001-12-07 22:04:19
|
On Friday 07 December 2001 02:45 pm, Tavis Rudd wrote: > But Geoff suggested that it might be better to require an explicit > arg to the start script to make damn sure it doesn't get them from > the wrong place. I don't think it's that likely. Nonetheless the > launcher script should loudly declare where it is getting its > settings from. We can mitigate that by printing the path info upon launching, as you've implied and advertising it in the admin servlets. > Personally I like your suggestion of using an env var. If we went > with a python package to contain the configs then you could use > PYTHONPATH to locate them, unless WEBWAREPATH was set. ... something > like that. > > The big question though is are we talking about 'WebKit' configs or > 'Webware' configs??? There's a big distinction there. 'Webware' > configs would allow us to deal with the settings for all Webware > components in one place. I don't think the local settings for > MiddleKit, UserKit, PieInTheSkyKit, etc. should be sitting in the > WebKitConfigs directory. Do you? Good point, but I wouldn't mind seeing all Python projects at least use the same path conventions for configs even if they're not Webware. Is CONFIGPATH too generic? Maybe PYCONFIGPATH? Well, it's back to contracting for me. Talk to you guys later. :-) -Chuck |
From: Chuck E. <Chu...@ya...> - 2001-12-07 21:56:33
|
On Tuesday 04 December 2001 06:01 pm, Tavis Rudd wrote: > * It requires Python 2.0 and up. I don't see any compelling reason > to continue support for 1.5.2. If people can install Webware they > can also install 2.0! If they're concerned about breaking existing > Apps by making that change, why don't they go through their Apps and > make the few minor changes that might be required. 0.6 (other than 0.6.x) is the last Webware version to support 1.5.2. 2.0 will be the new baseline for future versions. -Chuck |
From: Tavis R. <ta...@ca...> - 2001-12-07 22:01:22
|
On Friday 07 December 2001 13:55, Chuck Esterbrook wrote: > On Tuesday 04 December 2001 06:01 pm, Tavis Rudd wrote: > > * It requires Python 2.0 and up. =A0I don't see any compelling > > reason to continue support for 1.5.2. =A0If people can install > > Webware they can also install 2.0! =A0If they're concerned about > > breaking existing Apps by making that change, why don't they go > > through their Apps and make the few minor changes that might be > > required. > > 0.6 (other than 0.6.x) is the last Webware version to support > 1.5.2. > > 2.0 will be the new baseline for future versions. :) :) of course we could backport bits that people really need with 0.6 and=20 py 1.5.2 if they're stuck. |