For the record, I think it's important to remember that design docs are extensible, i.e. couchapp-style tools should also support 'fulltext' (couchdb-lucene), 'spatial' (geocouch), etc members. In general, that means blindly building a design doc from whatever bits (js, json, plain text) are on disk. I think both couchapp and erica handle this already.
I really see couchapp-style tools in a two parts: 1. Project starter. Dumps a typical directory structure to disk according to some template, e.g. erica's create-app and create-webapp or couchapp's startapp and generate commands. 2. Pull/clone. Updates a database from whatever is on disk or vice versa. Would it make sense to provide two distinct tools? The pull/clone tool might even be the only tool that's included in apache's couchdb distribution, which is likely to appeal to those who see couchdb as purely a database and should be easy to get in very quickly. - Matt On 4 December 2013 22:11, Benjamin Young <[email protected]> wrote: > On 11/30/13, 7:20 PM, Russell Branca wrote: >> >> A couple of options for approach would be to formalize the folder >> definition of a couchapp and list tools known to be compatible > > > First parts done: > https://github.com/couchapp/couchapp/wiki/Complete-Filesystem-to-Design-Doc-Mapping-Example > > erica and couchapp(.py) both support it. > > node.couchapp.js can also support the format if the app.js is setup properly > via couchapp.loadFiles() for each key. > > kan.so can as well: > http://kan.so/docs/Kanso_for_developers_using_the_python_couchapp_tool
