hubugs 0.9.1

Simple client for GitHub issues

Introduction

hubugs is a very simple client for working with GitHub’s issue tracker.

Requirements

hubugs requires Python v2.6 or above. hubugs’s mandatory dependencies outside of the standard library are argh, github2, Jinja and Pygments.

If you would like coloured terminal output, then you will need termcolor.

Configuration

Before using hubugs you must declare your authentication settings, so that we can access the API.

You first need to define your GitHub user name:

$ git config --global github.user username

And then you need to define your GitHub API token, this can be found in the account admin tab of your GitHub account page:

$ git config --global github.token token

Note

If you change your GitHub password your github.token setting will be invalid, and you must set it again.

If you wish to set the authentication information from the command line you can use the GITHUB_USER and GITHUB_TOKEN environment variables. For example:

$ GITHUB_USER=jnrowe GITHUB_TOKEN=xxx hubugs open

Contributors

I’d like to thank the following people who have contributed to hubugs.

Patches

<Your name here?>

Bug reports

• Brandon Cady

Ideas

• Matt Leighy

• Jules Marleau

If I’ve forgotten to include your name I wholeheartedly apologise. Just drop me a mail and I’ll update the list!

Hacking

Patches and pull requests are most welcome, but I’d appreciate it if you could follow the guidelines below to make it easier to integrate your changes. These are only guidelines however, and as such can be broken if the need arises or you just want to convince me that your style is better.

• PEP 8, the style guide, should be followed where possible.

• While support for Python versions prior to v2.6 may be added in the future if such a need were to arise, you are encouraged to use v2.6 features now.

• All new classes, methods and functions should be accompanied by new doctest examples and reStructuredText formatted descriptions.

• Tests must not span network boundaries, use of a mocking framework is acceptable.

• doctest tests in modules are only for unit testing in general, and should not rely on any modules that aren’t in Python’s standard library.

• Functional tests should be in the doc directory in reStructuredText formatted files, with actual tests in doctest blocks. Functional tests can depend on external modules, but those modules must be Open Source.

New examples for the doc directory are as appreciated as code changes.

Bugs

If you find any problems, bugs or just have a question about this package either file an issue or drop me a mail.

If you’ve found a problem please attempt to include a minimal testcase so I can reproduce the problem, or even better a patch!