I recently had to upgrade some legacy systems and build out a few new projects.
While doing this, I decided to standardize everything to a pattern/framework we've settled on over the past few years. This involved creating a cookiecutter based on the standard Pyramid cookiecutter, and I decided to open-source it as I've found it very useful. The cookiecutter does NOT generate a pyramid application, but instead generates the scaffolding to maintain complex Pyramid projects in version control. You still need to generate apps with the default cookiecutters (or import them into this scaffold) It's available via MIT license here: https://github.com/jvanasco/pyramid-cookiecutter-complex How does it work? The scaffold is designed to segment a Pyramid application into reusable components. While 95% of Pyramid users will be ecstatic with the standard project layout, some of us have seen projects grow incredibly large or had numerous side-projects and micro-sites bolted onto them. To handle this, the framework creates 3 python packages: project_core for shared functions, project_model for sqlalchemy/etc and project_pyramid for the pyramid app. The intent is for the output of a standard pyramid cookiecutter (your app) to exist in "project_pyramid". Various functions that are likely to be used across packages should be migrated to "project_core", and the sqlalchemy model migrated to "project_model". Additional packages can be developed alongside these. Several directories are used to organize server configuration files (e.g. nginx/apache), ssl certificates, sql schemas/triggers/views/etc, cronjobs, etc. Fabric is used to manage various operations like setup and deployment. The cookiecutter only ships with some installation and setup routines, as well as some code-quality routines that simply run black/flake8 on all the python packages. We also use Fabric for deployment and integrated testing, but those routines are all too specialized across our projects and I couldn't really abstract them. I'll make a few updates over the next week (or so) that better document some functions and try to open source more. The framework uses environment variables to change deployment context (development vs production), and file based semaphores to handle downtime (e.g. a Fabric command can touch a file to tell nginx we're in maintenance mode and serve a static site instead). -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/fbe3048d-a140-4a11-a450-0b05b3191f45n%40googlegroups.com.