Thanks for open-sourcing it. I don't know if I'll use this, but I have had occasions where I've thought about putting the models into a separate package, or where to store certificates and configurations, etc. I might look at the structure for ideas.
On Thu, Nov 10, 2022 at 5:21 PM Jonathan Vanasco <jvana...@gmail.com> wrote: > > 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. -- Mike Orr <sluggos...@gmail.com> -- 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/CAH9f%3Duro%2Bw_Ph8A_hKtTB1q%2BeQ2XyQO1DHEfOAXsJN2Hw2dp6Q%40mail.gmail.com.
