This document answers some parts of the question: what does Silver Lining do, and what does my app do?
The items listed here are things Silver Lining does for you, and so you shouldn’t do them for yourself.
To see if you are running in a Silver Lining production environment, check os.environ.get('SILVER_VERSION', '').startswith('silverlining/'). In development this variable will exist but start with 'devel/'.
If you need a “secret” (something random value that is persistent on the server), get it like:
from tcsupport.secret import get_secret
secret = get_secret()
This is a stable, ASCII secret. You don’t have to use this secret (you could put a secret in some config file, for instance), this is simply offered to you if you want to skip secret generation. It makes it easier to put configuration files into version control. This secret is not put in an environmental variable, because of a tendency of environmental variables to leak into error reports and other locations.
Just kidding; there is no special support for temporary files! This is just a reminder to use the tempfile module like usual; it works fine.
All persistence gets handled in some fashion by Silver Lining. This is just so Silver Lining knows about it, and so that your app handles what it should.
Persistent (as opposed to temporary) files need to be handled by Silver Lining. In your app.ini put:
service.files =
That line enables the service. Your application then gets the environmental variable:
You only get one location for files for your entire app, so it’s recommended you use additional directories under this location for different kinds of files (even if to start you can only think of one kind of file).
If you want to use SQLite you could simply require the necessary packages (python-sqlite) and then use this files service to store the database.
This is another place you can put files, except these files will be served up publicly. This location is essentially like the static/ directory. Files in static/ take precedence, but these files take precedence over the dynamic application. To enable use:
service.writable_root =
Your application gets the variable:
``CONFIG_WRITABLE_ROOT``:
Path where you can write these files.
Note index.html files will work.
Also you may put files in $CONFIG_WRITABLE_ROOT/$HTTP_HOST/... for per-host files. E.g., you can have an application serve up alice.myblogservice.com and bob.myblogservice.com, and put their files in $CONFIG_WRITABLE_ROOT/alice.myblogservice.com/ or $CONFIG_WRITABLE_ROOT/bob.myblogservice.com/ to keep the files host-local.
For PostGIS (PostgreSQL with the PostGIS extensions) do:
service.postgis =
Then look for these environmental variables:
Right now it’s always local, and there won’t be any password or host, but in the future that might change. And in development you can configure it however you want.
For MySQL do:
service.mysql =
Then look for these environmental variables:
Right now it’s always local, and there won’t be any password or host, but in the future that might change. And in development you can configure it however you want.
For CouchDB do:
service.couchdb =
Then look for:
For MongoDB do:
service.mongodb =
Then look for:
Currently this has several limitations:
It’s based on the very alpha ubuntu packages from 10gen It works on 9.10 (patching for older versions is simple, choosing is harder) It runs the lastest unsable mongodb currently 1.3.x it won’t install 1.2.x as no packages are avaliable for it
All your packages should be installed by Silver Lining. You can ask for a new (Ubuntu) package to be installed by putting this into your app.ini:
packages = package1
package2
This makes Silver Lining run apt-get install package1 package2 every time your application is update (conveniently if the packages are already installed then apt-get is fast and does nothing).
This all applies to local development (using silver serve), but Silver Lining does not actually setup any of this. It’s up to you to install the necessary servers, create the databases, etc.
You can do this however you want, and effect the configuration using ~/.silverlining.conf – each of these services looks for configuration overrides here. You should put this configuration in a section [devel] or [devel:APP_NAME] if you want to override a value just for one application (instead of all applications). You might do something like:
[devel]
# Use port 5433, where PG 8.3 is running:
postgis.host = localhost:5433
[devel:someapp]
postgis.dbname = foobar
Then all applications will look for the database at localhost:5433, and the someapp application will also use the database name foobar. If you put the literal string APP_NAME in any configuration value, that will be substituted with the application name; you might use it like:
[devel]
postgis.dbname = test_APP_NAME