Changes between Version 3 and Version 4 of TracDev/AlternativeFrontends

Timestamp:

Jul 27, 2015, 9:22:41 PM (9 years ago)

Author:

figaro

Comment:

Cosmetic changes

TracDev/AlternativeFrontends

@@ -3 +3 @@
 == Alternative frontend: mod_python
 
-Virtualenv can be used with Apache and mod_python, but as mod_python will be a system install it will not be aware of the virtualenv without some configuration. For development this is useful as one Apache can serve various development versions in a more permanent way. This method will use the system Python, but will add the libraries from the virtualenv.
+Virtualenv can be used with '''Apache''' and '''mod_python''', but as mod_python will be a system install, it will not be aware of the virtualenv without some configuration. For development this is useful as one Apache server can serve various development versions in a more permanent way. This method will use the system Python, but will add the libraries from the virtualenv.
 
-1. Make a new frontend script that for instance can be stored in the virtualenv `bin` directory.
+ 1. Make a new frontend script that for instance can be stored in the virtualenv `bin` directory:
  {{{#!python
 #myvirtualtrac.py
@@ -15 +15 @@
 from trac.web.modpython_frontend import handler
 }}}
-1. Update Apache config to use this script. Add or update options according to the default mod_python setup like for instance found in TracModPython.
+ 1. Update Apache config to use this script. Add or update options according to the default mod_python setup like for instance found in TracModPython:
  {{{#!apache
 # Extend the path so Apache will find your script on path
@@ -26 +26 @@
 == Alternative frontend: mod_wsgi
 
-Using Apache, mod_wsgi is a very good alternative to mod_python. Setting this up follows the same pattern, but for development especially there is one major advantage: It can quite easily be set up to auto-reload on code changes.
+With Apache, '''mod_wsgi''' is a very good alternative to '''mod_python'''. Setting this up follows the same pattern, but for development especially there is one major advantage: it can quite easily be set up to auto-reload on code changes.
 
-1. Update a default TracModWsgi setup to make a daemonised process, and as of mod_wsgi 2.0 (this setup depends on >= 2.0) there is built-in support for custom paths and similar. Example of a full `VirtualHost` configuration:
+ 1. Update a default TracModWsgi setup to make a daemonised process, and as of mod_wsgi 2.0 (this setup depends on >= 2.0) there is built-in support for custom paths and similar. Example of a full `VirtualHost` configuration:
  {{{#!apache
 <VirtualHost *:80>
@@ -61 +61 @@
 </VirtualHost>
 }}}
-1. Go to [mod-wsgi:ReloadingSourceCode#Monitoring_For_Code_Changes ReloadingSourceCode] and save the Python script as `/path/to/my/virtualenv/bin/monitor.py` 
-1. A basic WSGI frontend script, save as `/path/to/my/virtualenv/bin/virtualtrac.wsgi`
+ 1. Go to [mod-wsgi:ReloadingSourceCode#Monitoring_For_Code_Changes ReloadingSourceCode] and save the Python script as `/path/to/my/virtualenv/bin/monitor.py` 
+ 1. A basic WSGI frontend script, save as `/path/to/my/virtualenv/bin/virtualtrac.wsgi`:
  {{{#!python