Skip to content

janovergoor/rainbeard

Repository files navigation

Overview
========

Rainbeard is a next-generation trust network based on the principles of local
trust. See http://raincode.org/ for details on how it works.

Rainbeard is licensed under the GNU AGPL v3.

The current maintainer is: Bobby Holley <[email protected]>

Dependencies
============

Rainbeard is based on Django 1.3.

To run the test suite, you should also have the following software installed:
* pytidylib - http://countergram.com/open-source/pytidylib
* coverage.py - http://nedbatchelder.com/code/coverage/
* django test_coverage - http://opensource.55minutes.com/

Installing these should be straightforward:
easy_install pytidylib
easy_install coverage
svn co http://opensource.55minutes.com/svn/python/trunk/django/apps/test_coverage/

Installation
============

Rainbeard is technically a django app, but is designed to have a one-to-one
relationship with the site - that is to say, it may not coexist well with other
django apps.

The following steps should get you up and running:

1 - Create your django project and check out the rainbeard code

$ cd /my/code
$ django-admin.py startproject rainsite
$ cd rainsite
$ git clone git://github.com/bholley/rainbeard.git

2 - Edit settings.py

First configure your database. Sqlite is probably fine for all development that
doesn't involve performance testing. After setting up the database, add
/my/code/rainsite to the TEMPLATE_DIRS list. Next, comment out the CSRF
middleware (this will be fixed before the first release). Then, add 'rainbeard'
to INSTALLED_APPS. Finally, at the bottom of the file, add:

from rainbeard.settings import *

3 - Edit urls.py

Add the following line to the top of the file:

from rainbeard.urls import urls as rainbeard_urls

Next, add the following line to your url patterns:

url(r'', include(rainbeard_urls))

You may also wish to enable the django admin interface. See this page for more
information: https://docs.djangoproject.com/en/dev/intro/tutorial02/

4 - Populate the database

$ ./manage.py syncdb

You'll be asked to create a superuser. Go ahead and do that.

5 - Run the tests

$ ./manage.py test rainbeard

They should all pass.

6 - Generate a code coverage report

Check out the test_coverage app (mentioned above) into your rainsite directory.
Add 'test_coverage' to your list of INSTALLED_APPS in settings.py. At the bottom
of settings.py, add the following lines:

from test_coverage.settings import *
COVERAGE_REPORT_HTML_OUTPUT_DIR = '/where/i/want/the/coverage_report'

Make sure you create the directory where the coverage report will be placed. If
you don't, test_coverage will throw an exception.

$ ./manage.py test_coverage rainbeard

This should generate a code coverage report for you to inspect.

7 - Run the test server!

$ ./manage.py runserver


Development
===========

Code contributions are welcome. As always, it's best to check with the
maintainer to make sure you're on the same page before putting a lot of work
into a feature.

Git-style patches and GitHub pull requests are equally acceptable ways to submit
code. Both should be directed at the maintainer.

Any and all new code must have complete test coverage. Bug fixes should include
tests that fail without the fix. Nothing will be considered without tests. They
may be a pain to write, but they give you the peace of mind to know that your
hard work won't be broken later on when something else changes.

Please avoid combining many unrelated changes into a single changeset. If you're
using git for development, it's very easy to create separate branches for each
logically separate unit of change. If you find yourself working on a feature and
then spotting an unrelated bug, don't just fix the bug in the current branch.
Instead, do the following (assuming we're currently on branch my_feature_branch):


$ git stash                        # Save your current uncommited changes
$ git checkout -b my_fix_branch    # Create a new branch to hold your bugfix
$ ...hack...hack....
$ git commit                        # Commit your bugfix
$ git checkout my_feature_branch    # Return to your feature branch
$ git stash pop                     # Restore your working tree

This works great assuming that my_feature doesn't depend on my_fix. If it does,
you'll need to use rebase. See this page for more information:
http://kernel.org/pub/software/scm/git/docs/git-rebase.html

About

Next Generation Trust Network

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published