Fetching contributors…
Cannot retrieve contributors at this time
112 lines (73 sloc) 3.4 KB

SeqFindr Developer HOWTO

In addition to what is described here, this document by Jeff Forcier and this talk from Carl Meyer provide wonderful footings for developing on/in open source projects.

Maintaining a consistent development environment

1) Ensure all development in performed within a virtualenv. A good way too bootstrap this is via virtualenv-burrito.

Execute the installation using:

$ curl -sL | $SHELL

2) Make a virtualenv called SeqFindr:

$ mkvirtualenv SeqFindr

3) Install autoenv:

$ git clone git:// ~/.autoenv
$ echo 'source ~/.autoenv/' >> ~/.bashrc

Get the current code from GitHub

Something like this:

$ git clone

Install dependencies

Something like this:

$ cd SeqFindr
$ # Assuming you installed autoenv -
$ # You'll want to say 'y' as this will activate the virtualenv each time you enter the code directory
$ # Otherwise -
$ # workon SeqFindr
$ pip install -r requirements.txt
$ pip install -r requirements-dev.txt

Familiarise yourself with the code


Development workflow

Use GitHub. You will have already cloned the SeqFindr repo (if you followed instructions above). To make things easier, please fork ( and update your local copy to point to your fork.

Something like this:

$ # Assuming your fork is like this
$ vi .git/config
$ # Replace:
    $ # url =
$ #  with:
$ # url =$YOUR_USERNAME/SeqFindr.git

With this setup you will be able to push development changes to your fork and submit Pull Requests to the core SeqFindr repo when you're happy.

Important Note: Upstream changes will not be synced to your fork by default. Please, before submitting a pull request please sync your fork with any upstream changes (specifically handle any merge conflicts). Info on syncing a fork can be found here.

Code style/testing/Continuous Integration

We try to make joining and/or modifying the SeqFindr project simple.

  • As close to PEP8 as possible but I ain't no Saint. Just a long as it's clean and readable,
  • Using standard lib UnitTest. There are convenience functions & tests/ respectively. We would prefer SMART test vs 100 % coverage.
In the master GitHub repository we use hooks that call:
  • (code QC)
  • Travis CI (continuous integration)
  • ReadTheDocs (documentation building)