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.
