How it works pyramid_starter_seed

Note well that if you want to integrate a Pyramid application with the Yeoman workflow you can choose different strategies. So the pyramid_starter_seed's way is just one of the possible implementations.

.ini configurations

Production vs development .ini configurations.

Production:

1[app:main]
2use = egg:pyramid_starter_seed
3
4PRODUCTION = true
5minify = dist

Development:

1[app:main]
2use = egg:pyramid_starter_seed
3
4PRODUCTION = false
5minify = app

View callables

The view callable gets a different renderer depending on the production vs development settings:

1from pyramid.view import view_config
2
3@view_config(route_name='home', renderer='webapp/%s/index.html')
4def my_view(request):
5    return {'project': 'pyramid_starter_seed'}

Since there is no .html renderer, pyramid_starter_seed register a custom Pyramid renderer based on ZPT/Chameleon. See .html renderer

Templates

Css and javascript

 1<tal:production tal:condition="production">
 2    <script src="${request.static_url('pyramid_starter_seed:webapp/%s/scripts/plugins.js' % minify)}">
 3    </script>
 4</tal:production>
 5<tal:not_production tal:condition="not:production">
 6    <script src="${request.static_url('pyramid_starter_seed:webapp/%s/bower_components/bootstrap/js/alert.js' % minify)}">
 7    </script>
 8    <script src="${request.static_url('pyramid_starter_seed:webapp/%s/bower_components/bootstrap/js/dropdown.js' % minify)}">
 9    </script>
10</tal:not_production>
11<!-- build:js scripts/plugins.js -->
12<tal:comment replace="nothing">
13    <!-- DO NOT REMOVE this block (minifier) -->
14    <script src="./bower_components/bootstrap/js/alert.js"></script>
15    <script src="./bower_components/bootstrap/js/dropdown.js"></script>
16</tal:comment>
17<!-- endbuild -->

Note: the above verbose syntax could be avoided hacking with the grunt-bridge task. See grunt-bridge.

Images

<img class="logo img-responsive"
     src="${request.static_url('pyramid_starter_seed:webapp/%s/images/pyramid.png' % minify)}"
     alt="pyramid web framework" />

How to fork pyramid_starter_seed

Fetch pyramid_starter_seed, personalize it and then clone it!

Pyramid starter seed can be fetched, personalized and released with another name. So other developer can bootstrap, build, release and distribute their own starter templates without having to write a new package template generator. For example you could create a more opinionated starter seed based on SQLAlchemy, ZODB nosql or powered by a javascript framework like AngularJS and so on.

The clone method should speed up the process of creation of new more evoluted packages based on Pyramid, also people that are not keen on writing their own reusable scaffold templates.

So if you want to release your own customized template based on pyramid_starter_seed you'll have to call a console script named pyramid_starter_seed_clone with the following syntax (obviously you'll have to call this command outside the root directory of pyramid_starter_seed):

$ YOUR_VIRTUALENV_PYTHON_PATH/bin/pyramid_starter_seed_clone new_template

and you'll get as a result a perfect renamed clone new_template.

The clone console script it might not work in some corner cases just in case you choose a new package name that contains reserved words or the name of a dependency of your plugin, but it should be quite easy to fix by hand or improving the console script. But if you provide tests you can check immediately if something went wrong during the cloning process and fix.

How pyramid_starter_seed works under the hood

More details explained on the original article (part 3):