I've got to disagree with the chapter about settings files. Instead of maintaining multiple different settings for different environments, make your default settings file pull modifications for each environment from os.environ, e.g.:
Import a local_settings.py that isn't in the repository. Setting os environment variables and having multiple settings in the repository seems inflexible, a potential security problem, and just introduces unnecessary complexity to your application (doing different things because of a custom os environment variable). The security issue is production instructions in your main source repo, putting those instructions in a secured repo, hopefully maybe even encrypted, with limited access is probably more secure.
I use a version of that -- a single system variable identifying the environment and a series of conditional blocks for each environment in the settings.py file:
ENVIRONMENT = os.environ.get('ENVIRONMENT', None)
if not ENVIRONMENT in ('development', 'staging', 'production'):
raise Exception('You need to set ENVIRONMENT variable')
if ENVIRONMENT == 'development':
# ...
elif ENVIRONMENT == 'staging':
# ...
I have a strong preference for actual separate, situation-specific settings files. Mostly due to long, sorrowful experience debugging web server setups which were leaking environment variables across virtual hosts.
I think it's also worth linking to David Beazley's Curious Course on Coroutines and Concurrency [1]. It's exploring the ideas of a task scheduler implemented in Python. This article reminded me of it. It's not a full VM, but about half way into the PDF he goes into quite some detail on how to build a task scheduler modelled after an OS and how it works in an actual OS. Give it a read.
The issue I had with Pyjamas is that the whole tool-chain and compilation was a bit borked and the documentation a bit vague. After playing around with it for a day I decided it was too cumbersome so I ditched it in the end and tried py2js which Pyjaco is forked from. Mind you that was 2 years ago so a lot might have improved in that time but it convinced me that writing JS in Python is (was) not really feasible.
I really like that they opted to do everything over SSH in contrast to both Chef and Puppet that need a client/server configuration or at least some of their packages installed locally.
We do all of our deployments with Chef Solo and push our Cookbooks via Fabric over SSH to our servers. Pallet is definitely something to have a deeper look at as I don't like installing more than the bare essentials of what our apps need on our servers for various reasons.
It's still not properly packaged up and also nowhere to be found on http://pypi.python.org resulting in no pip and no easy_install options. Pretty much every useful python package is distributed that way, see httpie for example [1].
With that said, I think HN is the only community where the maintainer of the site merely has to wait until someone fixes usability problems themselves.
It is frustrating to see a slew of "Boy, this feature really sucks/broken/why isnt it here?" posts. Not because they are wrong (they are usually correct, like this post), but because the automatic solution is "fix it yourself" rather than "why hasn't pg fixed this?"
