File: contributing.rst

package info (click to toggle)
python-scrapy 0.14.4-1
  • links: PTS, VCS
  • area: main
  • in suites: wheezy
  • size: 3,064 kB
  • sloc: python: 19,468; xml: 199; sh: 134; makefile: 67
file content (162 lines) | stat: -rw-r--r-- 5,944 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
.. _topics-contributing:

======================
Contributing to Scrapy
======================

There are many ways to contribute to Scrapy. Here are some of them:

* Blog about Scrapy. Tell the world how you're using Scrapy. This will help
  newcomers with more examples and the Scrapy project to increase its
  visibility.

* Report bugs and request features in the `issue tracker`_, trying to follow
  the guidelines detailed in `Reporting bugs`_ below.

* Submit patches for new functionality and/or bug fixes. Please read
  `Writing patches`_ and `Submitting patches`_ below for details on how to
  write and submit a patch.

* Join the `scrapy-developers`_ mailing list and share your ideas on how to
  improve Scrapy. We're always open to suggestions.

Reporting bugs
==============

Well-written bug reports are very helpful, so keep in mind the following
guidelines when reporting a new bug.

* check the :ref:`FAQ <faq>` first to see if your issue is addressed in a
  well-known question

* check the `open issues`_ to see if it has already been reported. If it has,
  don't dismiss the report but check the ticket history and comments, you may
  find additional useful information to contribute.

* search the `scrapy-users`_ list to see if it has been discussed there, or
  if you're not sure if what you're seeing is a bug. You can also ask in the
  `#scrapy` IRC channel.

* write complete, reproducible, specific bug reports. The smaller the test
  case, the better. Remember that other developers won't have your project to
  reproduce the bug, so please include all relevant files required to reproduce
  it.

* include the output of ``scrapy version -v`` so developers working on your bug
  know exactly which version and platform it occurred on, which is often very
  helpful for reproducing it, or knowing if it was already fixed.

Writing patches
===============

The better written a patch is, the higher chance that it'll get accepted and
the sooner that will be merged.

Well-written patches should:

* contain the minimum amount of code required for the specific change. Small
  patches are easier to review and merge. So, if you're doing more than one
  change (or bug fix), please consider submitting one patch per change. Do not
  collapse multiple changes into a single patch. For big changes consider using
  a patch queue.

* pass all unit-tests. See `Running tests`_ below.

* include one (or more) test cases that check the bug fixed or the new
  functionality added. See `Writing tests`_ below.

* if you're adding or changing a public (documented) API, please include 
  the documentation changes in the same patch.  See `Documentation policies`_
  below.

Submitting patches
==================

The best way to submit a patch is to issue a `pull request`_ on Github,
optionally creating a new issue first.

Alternatively, we also accept the patches in the traditional way of sending
them to the `scrapy-developers`_ list.

Regardless of which mechanism you use, remember to explain what was fixed or
the new functionality (what it is, why it's needed, etc). The more info you
include, the easier will be for core developers to understand and accept your
patch.

You can also discuss the new functionality (or bug fix) in `scrapy-developers`_
first, before creating the patch, but it's always good to have a patch ready to
illustrate your arguments and show that you have put some additional thought
into the subject.

Coding style
============

Please follow these coding conventions when writing code for inclusion in
Scrapy:

* Unless otherwise specified, follow :pep:`8`.

* It's OK to use lines longer than 80 chars if it improves the code
  readability.

* Don't put your name in the code you contribute. Our policy is to keep
  the contributor's name in the `AUTHORS`_ file distributed with Scrapy.

Documentation policies
======================

* **Don't** use docstrings for documenting classes, or methods which are
  already documented in the official (sphinx) documentation. For example, the
  :meth:`ItemLoader.add_value` method should be documented in the sphinx
  documentation, not its docstring.

* **Do** use docstrings for documenting functions not present in the official
  (sphinx) documentation, such as functions from ``scrapy.utils`` package and
  its sub-modules.

Tests
=====

Tests are implemented using the `Twisted unit-testing framework`_ called
``trial``.

Running tests
-------------

To run all tests go to the root directory of Scrapy source code and run:

    ``bin/runtests.sh`` (on unix)

    ``bin\runtests.bat`` (on windows)

To run a specific test (say ``scrapy.tests.test_contrib_loader``) use:

    ``bin/runtests.sh scrapy.tests.test_contrib_loader`` (on unix)

    ``bin\runtests.bat scrapy.tests.test_contrib_loader`` (on windows)

Writing tests
-------------

All functionality (including new features and bug fixes) must include a test
case to check that it works as expected, so please include tests for your
patches if you want them to get accepted sooner.

Scrapy uses unit-tests, which are located in the ``scrapy.tests`` package
(`scrapy/tests`_ directory). Their module name typically resembles the full
path of the module they're testing. For example, the item loaders code is in::

    scrapy.contrib.loader

And their unit-tests are in::

    scrapy.tests.test_contrib_loader

.. _issue tracker: https://github.com/scrapy/scrapy/issues
.. _scrapy-users: http://groups.google.com/group/scrapy-users
.. _scrapy-developers: http://groups.google.com/group/scrapy-developers
.. _Twisted unit-testing framework: http://twistedmatrix.com/documents/current/core/development/policy/test-standard.html
.. _AUTHORS: https://github.com/scrapy/scrapy/blob/master/AUTHORS
.. _scrapy/tests: https://github.com/scrapy/scrapy/tree/master/scrapy/tests
.. _open issues: https://github.com/scrapy/scrapy/issues
.. _pull request: http://help.github.com/send-pull-requests/