[Checkins] SVN: zc.zope3recipes/branches/baijum-app-from-eggs/zc/zope3recipes/README.txt - Remove duplicate test cases

Baiju M baiju.m.mail at gmail.com
Tue Mar 20 04:56:31 EDT 2007


Log message for revision 73387:
   - Remove duplicate test cases
   - Delete trailing whitespaces
  

Changed:
  U   zc.zope3recipes/branches/baijum-app-from-eggs/zc/zope3recipes/README.txt

-=-
Modified: zc.zope3recipes/branches/baijum-app-from-eggs/zc/zope3recipes/README.txt
===================================================================
--- zc.zope3recipes/branches/baijum-app-from-eggs/zc/zope3recipes/README.txt	2007-03-20 08:50:24 UTC (rev 73386)
+++ zc.zope3recipes/branches/baijum-app-from-eggs/zc/zope3recipes/README.txt	2007-03-20 08:56:31 UTC (rev 73387)
@@ -13,11 +13,11 @@
 
 The "app" recipe is used to define a Zope application.  It is designed
 to work with classic Zope releases and with Zope solely as eggs.
-The app recipe causes a part to be created. The part will contain the 
+The app recipe causes a part to be created. The part will contain the
 scripts runzope and debugzope and the application's site.zcml.
 Both of the scripts will require providing a -C option and the path to a
 zope.conf file when run.  The debugzope script can be run with a script
-name and arguments, in which case it will run the script, rather than 
+name and arguments, in which case it will run the script, rather than
 starting an interactive session.
 
 The app recipe accepts the following options:
@@ -36,7 +36,7 @@
 
 eggs
   The names of one or more eggs, with their dependencies that should
-  be included in the Python path of the generated scripts. 
+  be included in the Python path of the generated scripts.
 
 Let's look at an example.  We'll make a faux zope installation:
 
@@ -47,14 +47,14 @@
 application:
 
     >>> mkdir('demo1')
-    >>> write('demo1', 'setup.py', 
+    >>> write('demo1', 'setup.py',
     ... '''
     ... from setuptools import setup
     ... setup(name = 'demo1')
     ... ''')
 
     >>> mkdir('demo2')
-    >>> write('demo2', 'setup.py', 
+    >>> write('demo2', 'setup.py',
     ... '''
     ... from setuptools import setup
     ... setup(name = 'demo2', install_requires='demo1')
@@ -68,7 +68,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = myapp
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...
@@ -157,7 +157,7 @@
 It includes in it's path the eggs we specified in the configuration
 file, along with their dependencies. Note that we haven't specified a
 configuration file.  When runzope is run, a -C option must be used to
-provide a configuration file.  -X options can also be provided to 
+provide a configuration file.  -X options can also be provided to
 override configuration file options.
 
 The debugzope script provides access to the object system.  When
@@ -205,7 +205,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = myapp
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...
@@ -260,7 +260,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = myapp
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...
@@ -309,18 +309,18 @@
 
 
 Run Application Solely from Eggs
--------------------------------
+--------------------------------
 
-To run a Zope 3 application solely from eggs, value of location in 
-zope3 section should set to empty.  Now we'll create a buildout.cfg
-file that defines our application with an empty location:
+To run a Zope 3 application solely from eggs, value of location in
+zope3 section should be set to empty.  Now we'll create a buildout.cfg
+file that defines our application with an empty location for zope3:
 
     >>> write('buildout.cfg',
     ... '''
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = myapp
-    ... 
+    ...
     ... [zope3]
     ... location =
     ...
@@ -341,56 +341,14 @@
     ... eggs = demo2
     ... ''' % globals())
 
-This is same as the example we have see above with a change in zope3 section.
-Note that our site.zcml file is very small.  It expect the application
-zcml to define almost everything.  In fact, a site.zcml file will often
-include just a single include directive.  We don't need to include the
-surrounding configure element, unless we want a namespace other than
-the zope namespace.  A configure directive will be included for us.
+Now, Let's run the buildout and see what we get:
 
-Let's run the buildout and see what we get:
-
     >>> print system(join('bin', 'buildout')),
     buildout: Develop: /sample-buildout/demo1
     buildout: Develop: /sample-buildout/demo2
     buildout: Uninstalling myapp
     buildout: Installing myapp
 
-A directory is created in the parts directory for our application files:
-
-    >>> ls('parts')
-    d  myapp
-
-    >>> ls('parts', 'myapp')
-    -  debugzope
-    -  runzope
-    -  site.zcml
-
-We get 3 files, two scripts and a site.zcml file.  The site.zcml file
-is just what we had in the buildout configuration:
-
-    >>> cat('parts', 'myapp', 'site.zcml')
-    <configure xmlns='http://namespaces.zope.org/zope'
-               xmlns:meta="http://namespaces.zope.org/meta"
-               >
-    <include package="demo2" />
-    <principal
-    id="zope.manager"
-    title="Manager"
-    login="jim"
-    password_manager="SHA1"
-    password="40bd001563085fc35165329ea1ff5c5ecbdbbeef"
-    />
-    <grant
-    role="zope.Manager"
-    principal="zope.manager"
-    />
-    </configure>
-
-Unfortunately, the leading whitespace is stripped from the
-configuration file lines.  This is a consequence of the way
-ConfigParser works.
-
 The runzope script runs the Web server:
 
     >>> cat('parts', 'myapp', 'runzope')
@@ -407,26 +365,9 @@
     if __name__ == '__main__':
         zope.app.twisted.main.main()
 
-It includes in it's path the eggs we specified in the configuration
-file, along with their dependencies. Note that we haven't specified a
-configuration file.  When runzope is run, a -C option must be used to
-provide a configuration file.  -X options can also be provided to 
-override configuration file options.
+Here, unlike the above example the location path is not included
+in sys.path .  Similarly debugzope script is also changed:
 
-The debugzope script provides access to the object system.  When
-debugzope is run, a -C option must be used to provide a configuration
-file.  -X options can also be provided to override configuration file
-options.  If run without any additional arguments, then an interactive
-interpreter will be started with databases specified in the
-configuration file opened and with the variable root set to the
-application root object.  The debugger variable is set to a Zope 3
-debugger.  If additional arguments are provided, then the first
-argument should be a script name and the remaining arguments are
-script arguments.  The script will be run with the root and debugger
-variables available as global variables.
-
-..
-
     >>> cat('parts', 'myapp', 'debugzope')
     #!/usr/local/bin/python2.4
     <BLANKLINE>
@@ -442,14 +383,7 @@
     if __name__ == '__main__':
         zc.zope3recipes.debugzope.debug()
 
-Note that the runzope shown above uses the default, twisted-based
-server components.  It's possible to specify which set of server
-components is used: the "servers" setting can be set to either
-"zserver" or "twisted".  For the application, this affects the runzope
-script; we'll see additional differences when we create instances of
-the application.
 
-
 Legacy Functional Testing Support
 ---------------------------------
 
@@ -463,7 +397,7 @@
 
 - It loads configurations for a large number of packages.  This has
   the potential to introduce testing dependency on all of these
-  packages. 
+  packages.
 
 - It required a ftesting.zcml file and makes assumptions about where
   that file is.  In particular, it assumes a location relative to the
@@ -475,7 +409,7 @@
 To support older packages that use the default layer, a ftesting.zcml
 option is provided.  If it is used, then the contents of the option
 are written to a ftesting.zcml file in the application.  In addition,
-an ftesting-base.zcml file is written that includes configuration 
+an ftesting-base.zcml file is written that includes configuration
 traditionally found in a Zope 3 ftesting-base.zcml excluding reference
 to package-includes.
 
@@ -486,7 +420,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = myapp
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...
@@ -603,7 +537,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = instance
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...
@@ -715,7 +649,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = instance
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...
@@ -794,7 +728,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = instance
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...
@@ -871,7 +805,7 @@
 from our application directory.
 
 We didn't specify any server or logging ZConfig sections, so some were
-generated for us.  
+generated for us.
 
 Note that, by default, the event-log output goes to standard output.
 We'll say more about that when we talk about the zdaemon
@@ -884,7 +818,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = instance
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...
@@ -966,7 +900,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = instance
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...
@@ -1048,7 +982,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = instance
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...
@@ -1123,7 +1057,7 @@
 
 Let's look at the zdaemon.conf file:
 
-    >>> cat('parts', 'instance', 'zdaemon.conf') 
+    >>> cat('parts', 'instance', 'zdaemon.conf')
     <runner>
       daemon on
       directory /sample-buildout/parts/instance
@@ -1153,7 +1087,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = instance
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...
@@ -1178,7 +1112,7 @@
     ... application = myapp
     ... zope.conf = ${database:zconfig}
     ... address = 8081
-    ... zdaemon.conf = 
+    ... zdaemon.conf =
     ...     <runner>
     ...       daemon off
     ...       socket-name /sample-buildout/parts/instance/sock
@@ -1271,7 +1205,7 @@
 etc-directory
     The name of the directory where configuration files should be
     placed.  This defaults to /etc/NAME, where NAME is the deployment
-    name. 
+    name.
 
 log-directory
     The name of the directory where application instances should write
@@ -1306,7 +1240,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = instance
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...
@@ -1450,7 +1384,7 @@
     ... [buildout]
     ... develop = demo1 demo2
     ... parts = instance instance2
-    ... 
+    ...
     ... [zope3]
     ... location = %(zope3)s
     ...



More information about the Checkins mailing list