This documents the procedure we used to setup a Grok virtual environment for working on the
Viejo content management system.  It assumes you have already run the two sudo commands on the
UbuntuGrok parent page.

  * {{{mkdir viejo_virtualenv}}}
  * {{{cd viejo_virtualenv}}}
  * {{{virtualenv --no-site-packages virtualgrok}}}
  * {{{source virtualgrok/bin/activate}}}
  * {{{easy_install grokproject}}}
  * {{{grokproject Viejo}}}
  * {{{cd Viejo}}}
  * {{{rm -rf setup.py buildout.cfg src}}}
  * {{{bzr checkout}}} [[https://launchpad.net/~viejo-team/viejo-code/yagni|lp:~viejo-team/viejo-code/yagni]] {{{.}}} (''Note:'' don't miss the dot at the end of this command.)
  * {{{./bin/buildout}}}
  * {{{./bin/test}}}

Now, we're good to go TDD. The main files and directories of our project are:

  * setup.py -> Mostly to include packages required for our project to work
  * buildout.cfg -> Configuration for our instance
  * src/viejo/models.py -> Stores the '''models''' of our application. See the [[http://en.wikipedia.org/wiki/Model-view-controller|Model-view-controller]] for more
  * src/viejo/tests -> Directory to store our unit doctests (Doctests are usually written in [[http://docutils.sourceforge.net/docs/user/rst/quickref.html|reStructuredText]])
  * src/viejo/tests/models.txt -> Unit doctests for our models.py module
  * src/viejo/ftests -> Directory to store our functional doctests
  * src/viejo/ftests/viejo.txt -> Functional doctests for our application

For every change we do to the application we always have to run {{{Viejo/bin/test}}} to check we don't break anything. We could access bin/test from anywhere in our path. For example, if we're inside our project's ftests directory we could call ../../../bin/test and it will run all our unit and functional tests. If we only want to run a kind of tests we could call it like this:

  * bin/test -u -> It will run only unit doctests inside the src/viejo/tests directory
  * bin/test -f -> It will run only functional doctests inside the src/viejo/ftests directory

Some useful bzr commands we will need:

  * bzr co lp:~viejo-team/viejo-code/yagni . -> It will check out our yagni branch inside the current directory. Why are we not using branches? Well, check out the '''When would I want a checkout?''' section of [[http://bazaar-vcs.org/CheckoutTutorial]]. Right now, I think it's OK working like this. Remember the name of our branch? ;)
  * bzr status -> It will tell us which files have been changed or deleted, which ones are about to be added to our branch and which ones are still unknown to bzr. '''Always''' use {{{bzr status}}} before doing a check in. Maybe our local setup works, but we have to make sure launchpad get all the files we want
  * bzr add <filename> -> Makes bzr to know about our new file
  * bzr remove <filename> -> Deletes a file from our project
  * bzr revert <filename> -> Restore <filename> to be the one we checked out
  * bzr ci -m "Some descriptive message" -> Checks changes back into launchpad (''note'': if you get an error when trying to commit that contains {{{Transport operation not possible: http does not support mkdir()}}}, you must first: {{{bzr switch lp:~viejo-team/viejo-code/yagni}}})

Some useful documentation urls we will need:
  * http://apidoc.zope.org -> This is the Zope 3 API Documentation

Whenever we want to start the zope server to check the functionality you do:
  * bin/zopectrl fg -> this starts the server and leaves the process on foreground