Contributing

Contributing

• Community Code of Conduct
  • Be considerate.
  • Be respectful.
  • Be collaborative.
  • When you disagree, consult others.
  • When you are unsure, ask for help.
  • Step down considerately.
• Reporting Bugs
  • Security
  • Other bugs
  • Issue Trackers
• Contributors guide to the codebase
• Versions
• Branches
  • master branch
  • Maintenance branches
  • Archived branches
  • Feature branches
• Tags
• Working on Features & Patches
  • Forking and setting up the repository
  • Running the unit test suite
  • Creating pull requests
    • Calculating test coverage
    • Running the tests on all supported Python versions
  • Building the documentation
  • Verifying your contribution
    • pyflakes & PEP8
    • API reference
• Coding Style
• Contributing features requiring additional libraries
• Contacts
  • Committers
    • Ask Solem
    • Mher Movsisyan
    • Steeve Morin
  • Website
    • Mauro Rocco
    • Jan Henrik Helmers
• Packages
  • celery
  • kombu
  • billiard
  • librabbitmq
  • celerymon
  • django-celery
  • cl
  • cyme
  • Deprecated
• Release Procedure
  • Updating the version number
  • Releasing

Community Code of Conduct

The goal is to maintain a diverse community that is pleasant for everyone. That is why we would greatly appreciate it if everyone contributing to and interacting with the community also followed this Code of Conduct.

The Code of Conduct covers our behavior as members of the community, in any forum, mailing list, wiki, website, Internet relay chat (IRC), public meeting or private correspondence.

The Code of Conduct is heavily based on the Ubuntu Code of Conduct, and the Pylons Code of Conduct.

Be considerate.

Your work will be used by other people, and you in turn will depend on the work of others. Any decision you take will affect users and colleagues, and we expect you to take those consequences into account when making decisions. Even if it’s not obvious at the time, our contributions to Ubuntu will impact the work of others. For example, changes to code, infrastructure, policy, documentation and translations during a release may negatively impact others work.

Be respectful.

The Celery community and its members treat one another with respect. Everyone can make a valuable contribution to Celery. We may not always agree, but disagreement is no excuse for poor behavior and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one. We expect members of the Celery community to be respectful when dealing with other contributors as well as with people outside the Celery project and with users of Celery.

Be collaborative.

Collaboration is central to Celery and to the larger free software community. We should always be open to collaboration. Your work should be done transparently and patches from Celery should be given back to the community when they are made, not just when the distribution releases. If you wish to work on new code for existing upstream projects, at least keep those projects informed of your ideas and progress. It many not be possible to get consensus from upstream, or even from your colleagues about the correct implementation for an idea, so don’t feel obliged to have that agreement before you begin, but at least keep the outside world informed of your work, and publish your work in a way that allows outsiders to test, discuss and contribute to your efforts.

When you disagree, consult others.

Disagreements, both political and technical, happen all the time and the Celery community is no exception. It is important that we resolve disagreements and differing views constructively and with the help of the community and community process. If you really want to go a different way, then we encourage you to make a derivative distribution or alternate set of packages that still build on the work we’ve done to utilize as common of a core as possible.

When you are unsure, ask for help.

Nobody knows everything, and nobody is expected to be perfect. Asking questions avoids many problems down the road, and so questions are encouraged. Those who are asked questions should be responsive and helpful. However, when asking a question, care must be taken to do so in an appropriate forum.

Step down considerately.

Developers on every project come and go and Celery is no different. When you leave or disengage from the project, in whole or in part, we ask that you do so in a way that minimizes disruption to the project. This means you should tell people you are leaving and take the proper steps to ensure that others can pick up where you leave off.

Reporting Bugs

Security

You must never report security related issues, vulnerabilities or bugs including senstive information to the bug tracker, or elsewhere in public. Instead sensitive bugs must be sent by email to security@celeryproject.org.

If you’d like to submit the information encrypted our PGP key is:

1. -----BEGIN PGP PUBLIC KEY BLOCK-----
2. Version: GnuPG v1.4.15 (Darwin)
4. mQENBFJpWDkBCADFIc9/Fpgse4owLNvsTC7GYfnJL19XO0hnL99sPx+DPbfr+cSE
5. 9wiU+Wp2TfUX7pCLEGrODiEP6ZCZbgtiPgId+JYvMxpP6GXbjiIlHRw1EQNH8RlX
6. cVxy3rQfVv8PGGiJuyBBjxzvETHW25htVAZ5TI1+CkxmuyyEYqgZN2fNd0wEU19D
7. +c10G1gSECbCQTCbacLSzdpngAt1Gkrc96r7wGHBBSvDaGDD2pFSkVuTLMbIRrVp
8. lnKOPMsUijiip2EMr2DvfuXiUIUvaqInTPNWkDynLoh69ib5xC19CSVLONjkKBsr
9. Pe+qAY29liBatatpXsydY7GIUzyBT3MzgMJlABEBAAG0MUNlbGVyeSBTZWN1cml0
10. eSBUZWFtIDxzZWN1cml0eUBjZWxlcnlwcm9qZWN0Lm9yZz6JATgEEwECACIFAlJp
11. WDkCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEOArFOUDCicIw1IH/26f
12. CViDC7/P13jr+srRdjAsWvQztia9HmTlY8cUnbmkR9w6b6j3F2ayw8VhkyFWgYEJ
13. wtPBv8mHKADiVSFARS+0yGsfCkia5wDSQuIv6XqRlIrXUyqJbmF4NUFTyCZYoh+C
14. ZiQpN9xGhFPr5QDlMx2izWg1rvWlG1jY2Es1v/xED3AeCOB1eUGvRe/uJHKjGv7J
15. rj0pFcptZX+WDF22AN235WYwgJM6TrNfSu8sv8vNAQOVnsKcgsqhuwomSGsOfMQj
16. LFzIn95MKBBU1G5wOs7JtwiV9jefGqJGBO2FAvOVbvPdK/saSnB+7K36dQcIHqms
17. 5hU4Xj0RIJiod5idlRC5AQ0EUmlYOQEIAJs8OwHMkrdcvy9kk2HBVbdqhgAREMKy
18. gmphDp7prRL9FqSY/dKpCbG0u82zyJypdb7QiaQ5pfPzPpQcd2dIcohkkh7G3E+e
19. hS2L9AXHpwR26/PzMBXyr2iNnNc4vTksHvGVDxzFnRpka6vbI/hrrZmYNYh9EAiv
20. uhE54b3/XhXwFgHjZXb9i8hgJ3nsO0pRwvUAM1bRGMbvf8e9F+kqgV0yWYNnh6QL
21. 4Vpl1+epqp2RKPHyNQftbQyrAHXT9kQF9pPlx013MKYaFTADscuAp4T3dy7xmiwS
22. crqMbZLzfrxfFOsNxTUGE5vmJCcm+mybAtRo4aV6ACohAO9NevMx8pUAEQEAAYkB
23. HwQYAQIACQUCUmlYOQIbDAAKCRDgKxTlAwonCNFbB/9esir/f7TufE+isNqErzR/
24. aZKZo2WzZR9c75kbqo6J6DYuUHe6xI0OZ2qZ60iABDEZAiNXGulysFLCiPdatQ8x
25. 8zt3DF9BMkEck54ZvAjpNSern6zfZb1jPYWZq3TKxlTs/GuCgBAuV4i5vDTZ7xK/
26. aF+OFY5zN7ciZHkqLgMiTZ+RhqRcK6FhVBP/Y7d9NlBOcDBTxxE1ZO1ute6n7guJ
27. ciw4hfoRk8qNN19szZuq3UU64zpkM2sBsIFM9tGF2FADRxiOaOWZHmIyVZriPFqW
28. RUwjSjs7jBVNq0Vy4fCu/5+e+XLOUBOoqtM5W7ELt0t1w9tXebtPEetV86in8fU2
29. =0chn
30. -----END PGP PUBLIC KEY BLOCK-----

Other bugs

Bugs can always be described to the Mailing list, but the best way to report an issue and to ensure a timely response is to use the issue tracker.

1. Create a GitHub account.

You need to create a GitHub account to be able to create new issues and participate in the discussion.

1. Determine if your bug is really a bug.

You should not file a bug if you are requesting support. For that you can use the Mailing list, or IRC.

1. Make sure your bug hasn’t already been reported.

Search through the appropriate Issue tracker. If a bug like yours was found, check if you have new information that could be reported to help the developers fix the bug.

1. Collect information about the bug.

To have the best chance of having a bug fixed, we need to be able to easily reproduce the conditions that caused it. Most of the time this information will be from a Python traceback message, though some bugs might be in design, spelling or other errors on the website/docs/code.

If the error is from a Python traceback, include it in the bug report.

We also need to know what platform you’re running (Windows, OSX, Linux, etc), the version of your Python interpreter, and the version of Celery, and related packages that you were running when the bug occurred.

1. Submit the bug.

By default GitHub will email you to let you know when new comments have been made on your bug. In the event you’ve turned this feature off, you should check back on occasion to ensure you don’t miss any questions a developer trying to fix the bug might ask.

Issue Trackers

Bugs for a package in the Celery ecosystem should be reported to the relevant issue tracker.

• Celery: http://github.com/celery/celery/issues/
• Django-Celery: http://github.com/celery/django-celery/issues
• Celery-Pylons: http://bitbucket.org/ianschenck/celery-pylons/issues
• Kombu: http://github.com/celery/kombu/issues

If you are unsure of the origin of the bug you can ask the Mailing list, or just use the Celery issue tracker.

Contributors guide to the codebase

There’s a seperate section for internal details, including details about the codebase and a style guide.

Read Contributors Guide to the Code for more!

Versions

Version numbers consists of a major version, minor version and a release number. Since version 2.1.0 we use the versioning semantics described by semver: http://semver.org.

Stable releases are published at PyPI while development releases are only available in the GitHub git repository as tags. All version tags starts with “v”, so version 0.8.0 is the tag v0.8.0.

Branches

Current active version branches:

• master (http://github.com/celery/celery/tree/master)
• 3.1 (http://github.com/celery/celery/tree/3.1)
• 3.0 (http://github.com/celery/celery/tree/3.0)

You can see the state of any branch by looking at the Changelog:

https://github.com/celery/celery/blob/master/Changelog

If the branch is in active development the topmost version info should contain metadata like:

1. 2.4.0
2. ======
3. :release-date: TBA
4. :status: DEVELOPMENT
5. :branch: master

The status field can be one of:

• PLANNING

  The branch is currently experimental and in the planning stage.

• DEVELOPMENT

  The branch is in active development, but the test suite should be passing and the product should be working and possible for users to test.

• FROZEN

  The branch is frozen, and no more features will be accepted. When a branch is frozen the focus is on testing the version as much as possible before it is released.

master branch

The master branch is where development of the next version happens.

Maintenance branches

Maintenance branches are named after the version, e.g. the maintenance branch for the 2.2.x series is named 2.2. Previously these were named releaseXX-maint.

The versions we currently maintain is:

• 2.3

  This is the current series.

• 2.2

  This is the previous series, and the last version to support Python 2.4.

• 2.1

  This is the last version to use the carrot AMQP library. Recent versions use kombu.

Archived branches

Archived branches are kept for preserving history only, and theoretically someone could provide patches for these if they depend on a series that is no longer officially supported.

An archived version is named X.Y-archived.

Our currently archived branches are:

• 2.1-archived
• 2.0-archived
• 1.0-archived

Feature branches

Major new features are worked on in dedicated branches. There is no strict naming requirement for these branches.

Feature branches are removed once they have been merged into a release branch.

Tags

Tags are used exclusively for tagging releases. A release tag is named with the format vX.Y.Z, e.g. v2.3.1. Experimental releases contain an additional identifier vX.Y.Z-id, e.g. v3.0.0-rc1. Experimental tags may be removed after the official release.

Working on Features & Patches

注解

Contributing to Celery should be as simple as possible, so none of these steps should be considered mandatory.

You can even send in patches by email if that is your preferred work method. We won’t like you any less, any contribution you make is always appreciated!

However following these steps may make maintainers life easier, and may mean that your changes will be accepted sooner.

Forking and setting up the repository

First you need to fork the Celery repository, a good introduction to this is in the Github Guide: Fork a Repo.

After you have cloned the repository you should checkout your copy to a directory on your machine:

1. $ git clone [email protected]:username/celery.git

When the repository is cloned enter the directory to set up easy access to upstream changes:

1. $ cd celery

1. $ git remote add upstream git://github.com/celery/celery.git

1. $ git fetch upstream

If you need to pull in new changes from upstream you should always use the —rebase option to git pull:

1. git pull --rebase upstream master

With this option you don’t clutter the history with merging commit notes. See Rebasing merge commits in git. If you want to learn more about rebasing see the Rebase section in the Github guides.

If you need to work on a different branch than master you can fetch and checkout a remote branch like this:

1. git checkout --track -b 3.0-devel origin/3.0-devel

For a list of branches see Branches.

Running the unit test suite

To run the Celery test suite you need to install a few dependencies. A complete list of the dependencies needed are located in requirements/test.txt.

Installing the test requirements:

1. $ pip install -U -r requirements/test.txt

When installation of dependencies is complete you can execute the test suite by calling nosetests:

1. $ nosetests

Some useful options to nosetests are:

• -x

  Stop running the tests at the first test that fails.

• -s

  Don’t capture output

• —nologcapture

  Don’t capture log output.

• -v

  Run with verbose output.

If you want to run the tests for a single test file only you can do so like this:

1. $ nosetests celery.tests.test_worker.test_worker_job

Creating pull requests

When your feature/bugfix is complete you may want to submit a pull requests so that it can be reviewed by the maintainers.

Creating pull requests is easy, and also let you track the progress of your contribution. Read the Pull Requests section in the Github Guide to learn how this is done.

You can also attach pull requests to existing issues by following the steps outlined here: http://bit.ly/koJoso

Calculating test coverage

Code coverage in HTML:

1. $ nosetests --with-coverage3 --cover3-html

The coverage output will then be located at celery/tests/cover/index.html.

Code coverage in XML (Cobertura-style):

1. $ nosetests --with-coverage3 --cover3-xml --cover3-xml-file=coverage.xml

The coverage XML output will then be located at coverage.xml

Running the tests on all supported Python versions

There is a tox configuration file in the top directory of the distribution.

To run the tests for all supported Python versions simply execute:

1. $ tox

If you only want to test specific Python versions use the -e option:

1. $ tox -e py26

Building the documentation

To build the documentation you need to install the dependencies listed in requirements/docs.txt:

1. $ pip install -U -r requirements/docs.txt

After these dependencies are installed you should be able to build the docs by running:

1. $ cd docs
2. $ rm -rf .build
3. $ make html

Make sure there are no errors or warnings in the build output. After building succeeds the documentation is available at .build/html.

Verifying your contribution

To use these tools you need to install a few dependencies. These dependencies can be found in requirements/pkgutils.txt.

Installing the dependencies:

1. $ pip install -U -r requirements/pkgutils.txt

pyflakes & PEP8

To ensure that your changes conform to PEP8 and to run pyflakes execute:

1. $ paver flake8

To not return a negative exit code when this command fails use the -E option, this can be convenient while developing:

1. $ paver flake8 -E

API reference

To make sure that all modules have a corresponding section in the API reference please execute:

1. $ paver autodoc
2. $ paver verifyindex

If files are missing you can add them by copying an existing reference file.

If the module is internal it should be part of the internal reference located in docs/internals/reference/. If the module is public it should be located in docs/reference/.

For example if reference is missing for the module celery.worker.awesome and this module is considered part of the public API, use the following steps:

1. $ cd docs/reference/
2. $ cp celery.schedules.rst celery.worker.awesome.rst

1. $ vim celery.worker.awesome.rst
3. # change every occurance of ``celery.schedules`` to
4. # ``celery.worker.awesome``

1. $ vim index.rst
3. # Add ``celery.worker.awesome`` to the index.

1. # Add the file to git
2. $ git add celery.worker.awesome.rst
3. $ git add index.rst
4. $ git commit celery.worker.awesome.rst index.rst \
5. -m "Adds reference for celery.worker.awesome"

Coding Style

You should probably be able to pick up the coding style from surrounding code, but it is a good idea to be aware of the following conventions.

• All Python code must follow the PEP-8 guidelines.

pep8.py is an utility you can use to verify that your code is following the conventions.

• Docstrings must follow the PEP-257 conventions, and use the following style.

  Do this:

  1. def method(self, arg):
  2. """Short description.
  4. More details.
  6. """

  or:

  1. def method(self, arg):
  2. """Short description."""

  but not this:

  1. def method(self, arg):
  2. """
  3. Short description.
  4. """

• Lines should not exceed 78 columns.

  You can enforce this in vim by setting the textwidth option:

  1. set textwidth=78

  If adhering to this limit makes the code less readable, you have one more character to go on, which means 78 is a soft limit, and 79 is the hard limit :)

• Import order

  • Python standard library (import xxx)
  • Python standard library (‘from xxx import`)
  • Third party packages.
  • Other modules from the current package.

  or in case of code using Django:

  • Python standard library (import xxx)
  • Python standard library (‘from xxx import`)
  • Third party packages.
  • Django packages.
  • Other modules from the current package.

  Within these sections the imports should be sorted by module name.

  Example:

  1. import threading
  2. import time
  4. from collections import deque
  5. from Queue import Queue, Empty
  7. from .datastructures import TokenBucket
  8. from .five import zip_longest, items, range
  9. from .utils import timeutils

• Wildcard imports must not be used (from xxx import *).

• For distributions where Python 2.5 is the oldest support version additional rules apply:

  • Absolute imports must be enabled at the top of every module:

    1. from __future__ import absolute_import

  • If the module uses the with statement and must be compatible with Python 2.5 (celery is not) then it must also enable that:

    1. from __future__ import with_statement

  • Every future import must be on its own line, as older Python 2.5 releases did not support importing multiple features on the same future import line:

    1. # Good
    2. from __future__ import absolute_import
    3. from __future__ import with_statement
    5. # Bad
    6. from __future__ import absolute_import, with_statement

    (Note that this rule does not apply if the package does not include support for Python 2.5)

• Note that we use “new-style` relative imports when the distribution does not support Python versions below 2.5

1. from . import submodule

Contributing features requiring additional libraries

Some features like a new result backend may require additional libraries that the user must install.

We use setuptools extra_requires for this, and all new optional features that require 3rd party libraries must be added.

1. Add a new requirements file in requirements/extras

   E.g. for the Cassandra backend this is requirements/extras/cassandra.txt, and the file looks like this:

   1. pycassa

   These are pip requirement files so you can have version specifiers and multiple packages are separated by newline. A more complex example could be:

   pycassa 2.0 breaks Foo pycassa>=1.0,<2.0 thrift

2. Modify setup.py

   After the requirements file is added you need to add it as an option to setup.py in the extras_require section:

   1. extra['extras_require'] = {
   2. # ...
   3. 'cassandra': extras('cassandra.txt'),
   4. }

3. Document the new feature in docs/includes/installation.txt

   You must add your feature to the list in the 捆绑 section of docs/includes/installation.txt.

   After you’ve made changes to this file you need to render the distro README file:

   1. $ pip install -U requirements/pkgutils.txt
   2. $ paver readme

That’s all that needs to be done, but remember that if your feature adds additional configuration options then these needs to be documented in docs/configuration.rst. Also all settings need to be added to the celery/app/defaults.py module.

Result backends require a separate section in the docs/configuration.rst file.

Contacts

This is a list of people that can be contacted for questions regarding the official git repositories, PyPI packages Read the Docs pages.

If the issue is not an emergency then it is better to report an issue.

Committers

Ask Solem

Mher Movsisyan

Steeve Morin

Website

The Celery Project website is run and maintained by

Mauro Rocco

with design by:

Jan Henrik Helmers

Packages

celery

kombu

Messaging library.

billiard

Fork of multiprocessing containing improvements that will eventually be merged into the Python stdlib.

librabbitmq

Very fast Python AMQP client written in C.

celerymon

Celery monitor web-service.

django-celery

Django <-> Celery Integration.

cl

Actor library.

cyme

Distributed Celery Instance manager.

Deprecated

• Flask-Celery

• carrot

• ghettoq

• kombu-sqlalchemy

• django-kombu

• pylibrabbitmq

Old name for librabbitmq.

Release Procedure

Updating the version number

The version number must be updated two places:

• celery/__init__.py
• docs/include/introduction.txt

After you have changed these files you must render the README files. There is a script to convert sphinx syntax to generic reStructured Text syntax, and the paver task readme does this for you:

1. $ paver readme

Now commit the changes:

1. $ git commit -a -m "Bumps version to X.Y.Z"

and make a new version tag:

1. $ git tag vX.Y.Z
2. $ git push --tags

Releasing

Commands to make a new public stable release:

1. $ paver releaseok  # checks pep8, autodoc index, runs tests and more
2. $ paver removepyc  # Remove .pyc files
3. $ git clean -xdn   # Check that there's no left-over files in the repo
4. $ python setup.py sdist upload  # Upload package to PyPI

If this is a new release series then you also need to do the following:

• Go to the Read The Docs management interface at:

  http://readthedocs.org/projects/celery/?fromdocs=celery

• Enter “Edit project”

  Change default branch to the branch of this series, e.g. 2.4 for series 2.4.

• Also add the previous version under the “versions” tab.