- Please sign one of the contributor license agreements below.
- Fork the repo, develop and test your code changes, add docs.
- Make sure that your commit messages clearly describe the changes.
- Send a pull request.
Here are some guidelines for hacking on gcloud-python.
You'll have to create a development environment to hack on gcloud-python, using a Git checkout:
While logged into your GitHub account, navigate to the gcloud-python repo on GitHub.
Fork and clone the gcloud-python repository to your GitHub account by clicking the "Fork" button.
Clone your fork of gcloud-python from your GitHub account to your local computer, substituting your account username and specifying the destination as "hack-on-gcloud". E.g.:
$ cd ~ $ git clone git@github.com:USERNAME/gcloud-python.git hack-on-gcloud $ cd hack-on-gcloud # Configure remotes such that you can pull changes from the gcloud-python # repository into your local repository. $ git remote add upstream https://github.com:GoogleCloudPlatform/gcloud-python # fetch and merge changes from upstream into master $ git fetch upstream $ git merge upstream/master
Now your local repo is set up such that you will push changes to your GitHub repo, from which you can submit a pull request.
Create a virtualenv in which to install gcloud-python:
$ cd ~/hack-on-gcloud $ virtualenv -ppython2.7 env
Note that very old versions of virtualenv (virtualenv versions below, say, 1.10 or thereabouts) require you to pass a
--no-site-packagesflag to get a completely isolated environment.You can choose which Python version you want to use by passing a
-pflag tovirtualenv. For example,virtualenv -ppython2.7chooses the Python 2.7 interpreter to be installed.From here on in within these instructions, the
~/hack-on-gcloud/envvirtual environment you created above will be referred to as$VENV. To use the instructions in the steps that follow literally, use theexport VENV=~/hack-on-gcloud/envcommand.Install gcloud-python from the checkout into the virtualenv using
setup.py develop. Runningsetup.py developmust be done while the current working directory is thegcloud-pythoncheckout directory:$ cd ~/hack-on-gcloud $ $VENV/bin/python setup.py develop
Chances are you have some dependency problems... If you're on Ubuntu, try installing the pre-compiled packages:
$ sudo apt-get install python-crypto python-openssl libffi-dev
or try installing the development packages
(that have the header files included)
and then pip install the dependencies again:
$ sudo apt-get install python-dev libssl-dev libffi-dev $ pip install gcloud
In order to add a feature to gcloud-python:
- The feature must be documented in both the API and narrative
documentation (in
docs/). - The feature must work fully on the following CPython versions: 2.6, and 2.7 on both UNIX and Windows.
- The feature must not add unnecessary dependencies (where "unnecessary" is of course subjective, but new dependencies should be discussed).
PEP8 compliance, with exceptions defined in
tox.ini. If you havetoxinstalled, you can test that you have not introduced any non-compliant code via:$ tox -e lint
Exceptions to PEP8:
- Many unit tests use a helper method,
_callFUT("FUT" is short for "Function-Under-Test"), which is PEP8-incompliant, but more readable. Some also use a local variable,MUT(short for "Module-Under-Test").
To run all tests for gcloud-python on a single Python version, run
nosetestsfrom your development virtualenv (See Using a Development Checkout above).To run the full set of gcloud-python tests on all platforms, install
tox(http://codespeak.net/~hpk/tox/) into a system Python. Thetoxconsole script will be installed into the scripts location for that Python. Whilecd'ed to the gcloud-python checkout root directory (it containstox.ini), invoke thetoxconsole script. This will read thetox.inifile and execute the tests on multiple Python versions and platforms; while it runs, it creates a virtualenv for each version/platform combination. For example:$ sudo /usr/bin/pip install tox $ cd ~/hack-on-gcloud/ $ /usr/bin/tox
The codebase must have 100% test statement coverage after each commit. You can test coverage via
tox -e coverage, or alternately by installingnoseandcoverageinto your virtualenv, and runningsetup.py nosetests --with-coverage. If you havetoxinstalled:$ tox -e cover
If you fix a bug, and the bug requires an API or behavior modification, all documentation in this package which references that API or behavior must be changed to reflect the bug fix, ideally in the same commit that fixes the bug or adds the feature.
To build and review docs (where $VENV refers to the virtualenv you're
using to develop gcloud-python):
After following the steps above in "Using a Development Checkout", install Sphinx and all development requirements in your virtualenv:
$ cd ~/hack-on-gcloud $ $VENV/bin/pip install Sphinx
Change into the
docsdirectory within your gcloud-python checkout and execute themakecommand with some flags:$ cd ~/hack-on-gcloud/gcloud-python/docs $ make clean html SPHINXBUILD=$VENV/bin/sphinx-build
The
SPHINXBUILD=...argument tells Sphinx to use the virtualenv Python, which will have both Sphinx and gcloud-python (for API documentation generation) installed.Open the
docs/_build/html/index.htmlfile to see the resulting HTML rendering.
As an alternative to 1. and 2. above, if you have tox installed, you
can build the docs via:
$ tox -e docs
Before we can accept your pull requests you'll need to sign a Contributor License Agreement (CLA):
- If you are an individual writing original source code and you own the intellectual property, then you'll need to sign an individual CLA.
- If you work for a company that wants to allow you to contribute your work, then you'll need to sign a corporate CLA.
You can sign these electronically (just scroll to the bottom). After that, we'll be able to accept your pull requests.