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 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 Model-view-controller for more

• src/viejo/tests -> Directory to store our unit doctests (Doctests are usually written in 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