One change I have thought of since:
Instead of 'requiredPySoftware' and 'integratesWithPySoftware' as described
below, I was thinking of:
* Removing the "Py"
* Going with dictionaries instead of tuples.
* Keys are "type", "name" and "version".
* "type" is optional and defaults to "python"
requiredSoftware = [
{ 'name': 'MySQLdb', 'version': (0,3,0) },
{ 'name': 'mx' },
]
The idea with this new format is that we could expand to other types of
software in the future without breaking or changing existing Properties.py
files.
-Chuck
At 10:42 AM 1/24/2001 -0500, Geoff Talvola wrote:
>Sounds like a good idea to me. COMKit and your MySQL stuff would
>certainly be able to make use of it.
>
>Chuck Esterbrook wrote:
>
> > Here's a "WEP" or "Webware Enhancement Proposal". The format is still
> informal.
> >
> > Please review and comment as appropriate.
> >
> > Webware Enhancement Proposal
> >
> > Name: Additional Properties
> > Author: Chuck Esterbrook
> > Created: 1/20/2001
> >
> > BACKGROUND
> > ----------
> > Webware is composed of components, which are fairly independent Python
> > packages. Example components include WebKit, PSP, UserKit and MiscUtils.
> >
> > Each Webware component has a Properties.py file that advertises various
> things:
> >
> > name = 'WebKit'
> > version = (0, 5, 0, 'pre')
> > docs = [
> > {'name': 'Install Guide', 'file': 'InstallGuide.html'},
> > {'name': "User's Guide", 'file': 'UsersGuide.html'},
> > ]
> > status = 'beta'
> > requiredPyVersion = (1, 5, 2)
> > synopsis = '''WebKit provides Python classes for generating dynamic content
> > ... '''
> >
> > This information is used in:
> > * Generated documentation
> > - Webware/Docs/ComponentIndex.html
> > - <Component>/Docs/index.html
> > * WebKit when loading plug-ins (TBD)
> >
> > PROPOSAL
> > --------
> > Extend the conventions with additional variables. First, the examples:
> >
> > requiredOpSys = ['ce']
> > deniedOpSys = ['dos']
> > requiredPySoftware = [
> > ('module', 'MySQLdb', (0,3,0)),
> > ('package', 'mx'),
> > ('component', 'WebKit', (0,5,0)),
> > ]
> > integratesWithPySoftware = [
> > ('component', 'WebKit'),
> > ]
> > def willRun():
> > import os
> > return os.environ.has_key('/tmp')
> >
> > requiredOpSys - a list of one or more op sys that are required in order
> to run.
> >
> > deniedOpSys - a list of one or more op sys for which this component will
> > not run.
> >
> > Op sys notes:
> > - Having both a requiredOpSys and deniedOpSys does not make
> much sense.
> > - The op sys names are matched up against os.name which as of
> Py 2.0 is
> > documented as: 'posix', 'nt', 'dos', 'mac', 'os2', 'ce' or 'java'.
> >
> > requiredPySoftware - a list of Python software that the component requires.
> > Each item is a tuple specifying the type of software, its name and
> > optionally its minimum version. Types include module, package and
> component.
> >
> > integratesWithPySoftware - a list of Python software that will
> > automatically be incorporated and/or extended by the component, if that
> > software exists. Same format as requiredPySoftware.
> >
> > willRun - a function that returns 1 if the component will run on the
> > current machine in the current environment; 0 otherwise. This function need
> > not check other properties (op sys, required py version, required software
> > components) since the application framework will check those first and only
> > invoke willRun() if those tests pass. willRun() is intended to capture
> > non-trivial conditions which cannot be expressed with the other settings.
> >
> > WebKit would be enhanced to use requiredOpSys, deniedOpSys and
> > requiredPySoftware when loading plug-ins (which are always components). The
> > Webware generated docs would also be enhanced to take advantage of the
> > extra information.
> >
> > The major benefit is that by allowing components to specify this
> > information, the application framework can manage them better, and the
> > documentation will more immediately reflect important characteristics like
> > dependencies.
> >
> > OPEN CONSIDERATIONS
> > -------------------
> > * Does the format for requiredPySoftware and integrateWithPySoftware really
> > require the "type" of software as in 'module', 'package', 'component'?
> > These can all be tested for by an import or even an imp.find_module.
> > Although having the type would allow for other types in the future (shared
> > libraries/DLLs, scripts, RPMs, etc). We could also switch to a dictionary
> > format and make that key optional. When not present, the software type
> > would be assumed to be "Python importable".
> >
> > _______________________________________________
> > Webware-discuss mailing list
> > Webware-discuss@...
> > http://lists.sourceforge.net/lists/listinfo/webware-discuss
>
>--
>
>
>- Geoff Talvola
> Parlance Corporation
> gtalvola@...
|