@longjon @shelhamer What do you think?

@shelhamer @jeffdonahue @longjon do you know how to avoid time-out errors in Travis?
How do I make it run again?

Hi @sguada, thanks for your job on template layers. It's so useful for designing large network.

But I found it inconvenient to fill all the variables in a template including those variables we want to keep their default values. So I make a python script to add missing variable support in expand_net based on your expand_net.cpp. Those missing variables will be omitted in the template after expanded (so that they keep their default values).

See https://github.com/7hil/caffe/blob/py_template_layer/python/expand_net.py for more detail.
PS: So far I just use regexp to delete those missing variables.

@7hil it's nice to have a python version too, but could you maintain the same conventions for replacing variables. It is a good idea to remove missing variables, although it will be better that the template could define its own default values.

${name} -> value
"${name}" -> "value"

@sguada I've removed the $${name} replacement and add basic default value support in template.
To set the default value in template, use ${name=default}.

Thanks for your code @7hil I added your expand_net.py to this PR

The added Inception, aux_classifier and GoogleNet templates were used to generate the prototxt for GoogleNet in #1598

Great.
Have you planned to support default value in the template layer in expand_net.cpp? @sguada

@7hil I haven't added the support for defaults in the .cpp code, but if you want to add it, it will be great.

@sguada @jeffdonahue @longjon

I think Python net specification #1733 is a more general and concise means to generate networks. I'm not entirely comfortable with building in string processing for network definitions. I worry about the proliferation of templates too when the Python net specification can make use of whatever logic and modularity one might want. This alternative does require Python however.

Is it alright to close this in favor of #1733?

Closing since Python net specification was adopted instead.