Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(6)

Unified Diff: third_party/gsutil/boto/docs/source/contributing.rst

Issue 12317103: Added gsutil to depot tools (Closed) Base URL: https://chromium.googlesource.com/chromium/tools/depot_tools.git@master
Patch Set: added readme Created 7 years, 10 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
Index: third_party/gsutil/boto/docs/source/contributing.rst
diff --git a/third_party/gsutil/boto/docs/source/contributing.rst b/third_party/gsutil/boto/docs/source/contributing.rst
new file mode 100644
index 0000000000000000000000000000000000000000..ac9305a3341699f8d397e426c15dee875b4f6ca9
--- /dev/null
+++ b/third_party/gsutil/boto/docs/source/contributing.rst
@@ -0,0 +1,204 @@
+====================
+Contributing to Boto
+====================
+
+
+Setting Up a Development Environment
+====================================
+
+While not strictly required, it is highly recommended to do development
+in a virtualenv. You can install virtualenv using pip::
+
+ $ pip install virtualenv
+
+Once the package is installed, you'll have a ``virtualenv`` command you can
+use to create a virtual environment::
+
+ $ virtualenv venv
+
+You can then activate the virtualenv::
+
+ $ . venv/bin/activate
+
+.. note::
+
+ You may also want to check out virtualenvwrapper_, which is a set of
+ extensions to virtualenv that makes it easy to manage multiple virtual
+ environments.
+
+A requirements.txt is included with boto which contains all the additional
+packages needed for boto development. You can install these packages by
+running::
+
+ $ pip install -r requirements.txt
+
+
+Running the Tests
+=================
+
+All of the tests for boto are under the ``tests/`` directory. The tests for
+boto have been split into two main categories, unit and integration tests:
+
+* **unit** - These are tests that do not talk to any AWS services. Anyone
+ should be able to run these tests without have any credentials
+ configured. These are the types of tests that could be run in something
+ like a public CI server. These tests tend to be fast.
+
+* **integration** - These are tests that will talk to AWS services, and
+ will typically require a boto config file with valid credentials.
+ Due to the nature of these tests, they tend to take a while to run.
+ Also keep in mind anyone who runs these tests will incur any usage
+ fees associated with the various AWS services.
+
+To run all the unit tests, cd to the ``tests/`` directory and run::
+
+ $ python test.py unit
+
+You should see output like this::
+
+ $ python test.py unit
+ ................................
+ ----------------------------------------------------------------------
+ Ran 32 tests in 0.075s
+
+ OK
+
+To run the integration tests, run::
+
+ $ python test.py integration
+
+Note that running the integration tests may take a while.
+
+Various integration tests have been tagged with service names to allow
+you to easily run tests by service type. For example, to run the ec2
+integration tests you can run::
+
+ $ python test.py -t ec2
+
+You can specify the ``-t`` argument multiple times. For example, to
+run the s3 and ec2 tests you can run::
+
+ $ python test.py -t ec2 -t s3
+
+.. warning::
+
+ In the examples above no top level directory was specified. By default,
+ nose will assume the current working directory, so the above command is
+ equivalent to::
+
+ $ python test.py -t ec2 -t s3 .
+
+ Be sure that you are in the ``tests/`` directory when running the tests,
+ or explicitly specify the top level directory. For example, if you in the
+ root directory of the boto repo, you could run the ec2 and s3 tests by
+ running::
+
+ $ python tests/test.py -t ec2 -t s3 tests/
+
+
+You can use nose's collect plugin to see what tests are associated with each
+service tag::
+
+ $ python tests.py -t s3 -t ec2 --with-id --collect -v
+
+
+Testing Details
+---------------
+
+The ``tests/test.py`` script is a lightweight wrapper around nose_. In
+general, you should be able to run ``nosetests`` directly instead of
+``tests/test.py``. The ``tests/unit`` and ``tests/integration`` args
+in the commands above were referring to directories. The command line
+arguments are forwarded to nose when you use ``tests/test.py``. For example,
+you can run::
+
+ $ python tests/test.py -x -vv tests/unit/cloudformation
+
+And the ``-x -vv tests/unit/cloudformation`` are forwarded to nose. See
+the nose_ docs for the supported command line options, or run
+``nosetests --help``.
+
+The only thing that ``tests/test.py`` does before invoking nose is to
+inject an argument that specifies that any testcase tagged with "notdefault"
+should not be run. A testcase may be tagged with "notdefault" if the test
+author does not want everyone to run the tests. In general, there shouldn't be
+many of these tests, but some reasons a test may be tagged "notdefault"
+include:
+
+* An integration test that requires specific credentials.
+* An interactive test (the S3 MFA tests require you to type in the S/N and
+ code).
+
+Tagging is done using nose's tagging_ plugin. To summarize, you can tag a
+specific testcase by setting an attribute on the object. Nose provides
+an ``attr`` decorator for convenience::
+
+ from nose.plugins.attrib import attr
+
+ @attr('notdefault')
+ def test_s3_mfs():
+ pass
+
+You can then run these tests be specifying::
+
+ nosetests -a 'notdefault'
+
+Or you can exclude any tests tagged with 'notdefault' by running::
+
+ nosetests -a '!notdefault'
+
+Conceptually, ``tests/test.py`` is injecting the "-a !notdefault" arg
+into nosetests.
+
+
+Testing Supported Python Versions
+==================================
+
+Boto supports python 2.6 and 2.7. An easy way to verify functionality
+across multiple python versions is to use tox_. A tox.ini file is included
+with boto. You can run tox with no args and it will automatically test
+all supported python versions::
+
+ $ tox
+ GLOB sdist-make: boto/setup.py
+ py26 sdist-reinst: boto/.tox/dist/boto-2.4.1.zip
+ py26 runtests: commands[0]
+ ................................
+ ----------------------------------------------------------------------
+ Ran 32 tests in 0.089s
+
+ OK
+ py27 sdist-reinst: boto/.tox/dist/boto-2.4.1.zip
+ py27 runtests: commands[0]
+ ................................
+ ----------------------------------------------------------------------
+ Ran 32 tests in 0.087s
+
+ OK
+ ____ summary ____
+ py26: commands succeeded
+ py27: commands succeeded
+ congratulations :)
+
+
+Writing Documentation
+=====================
+
+The boto docs use sphinx_ to generate documentation. All of the docs are
+located in the ``docs/`` directory. To generate the html documentation, cd
+into the docs directory and run ``make html``::
+
+ $ cd docs
+ $ make html
+
+The generated documentation will be in the ``docs/build/html`` directory.
+The source for the documentation is located in ``docs/source`` directory,
+and uses `restructured text`_ for the markup language.
+
+
+.. _nose: http://readthedocs.org/docs/nose/en/latest/
+.. _tagging: http://nose.readthedocs.org/en/latest/plugins/attrib.html
+.. _tox: http://tox.testrun.org/latest/
+.. _virtualenvwrapper: http://www.doughellmann.com/projects/virtualenvwrapper/
+.. _sphinx: http://sphinx.pocoo.org/
+.. _restructured text: http://sphinx.pocoo.org/rest.html

Powered by Google App Engine
This is Rietveld 408576698