geckoboard-python 0.3.1

# gecko-dataset #

[](https://travis-ci.org/helium/geckoboard-python) [](https://coveralls.io/github/helium/geckoboard-python?branch=master) [](https://codeclimate.com/github/helium/geckoboard-python)

geckoboard-python is a Python package that makes creating and managing [datasets](https://developer.geckoboard.com/api-reference/curl/) for the [Geckboard](https://geckoboard.com) service easier.

## Installation

Assuming you’re using pip, add this line to your setup.py:

` requires = ['geckoboard-python] `

or to your requirements.txt file:

` geckoboard-python `

## Usage and Documentation

## Development

In order to develop for this code-base you will need to install tox:

` pip install tox `

Since geckoboard-python supports at least Python 2.7 and 3.5 you will need to have at least one of those installed on your development machine. The build automation will test all required versions when code is pushed to this repository.

Clone this repository and run:

` $ tox `

This will install the required packages and run the tests for the library. Installing tox removes the need to install or use virtualenv since tox manages virtual environments already.

By default the tests will replay back previously recorded API interactions. To affect how tests interact with the API you will have to

• Set a GECKO_API_KEY environment variable to a valid Geckboard API key. For example in bash:

` $ export GECKO_API_KEY=<my api key> `

• Set GECKO_RECORD_MODE to one of:

• none - (default) Only play back recorded API interactions.

• once - Only record interactions for which no recording exist. If you get an error message from betamax complaining about a recording not matching an interaction that means that your test has new API interactions with it. Remove the cassette referred to in the error message and run the test again to re-generate it .

We use flake8 to ensure we catch Python version differences and common pitfalls quicker. Please run:

` $ tox -e lint `

before you commit code and try to remove as many warnings as you can. Once we figure out how strict some of the documentation requirements need to be we will be running lint as part of automation.

To make a release tag the repository with a valid [semantic version](https://semver.org) version and push tags. The build automation will automatically build and push releases to [PyPi](https://pypi.python.org).