寄稿—Pythonドキュメント

提供：Dev Guides
Celery/docs/latest/contributing
移動先:案内、検索

貢献

いらっしゃいませ！

このドキュメントはかなり広範であり、小さな貢献のためにこれを詳細に研究することは実際には期待されていません。

最も重要なルールは、貢献は簡単でなければならず、コミュニティは友好的であり、コーディングスタイルなどの詳細を軽視してはならないということです。


バグを報告する場合は、以下の「バグの報告」セクションを読んで、バグレポートに問題を正常に診断するのに十分な情報が含まれていることを確認する必要があります。コードを提供する場合は、コードを取り巻く規則を模倣するようにしてください。作業中ですが、最終的にはすべてのパッチが変更をマージする人によってクリーンアップされるので、あまり心配しないでください。


コミュニティ行動規範

目標は、誰にとっても快適な多様なコミュニティを維持することです。 だからこそ、コミュニティに貢献し、コミュニティと交流するすべての人がこの行動規範に従えば、私たちは大いに感謝します。

行動規範は、フォーラム、メーリングリスト、ウィキ、ウェブサイト、インターネットリレーチャット（IRC）、公開会議、または私的な通信における、コミュニティのメンバーとしての私たちの行動を対象としています。

行動規範は、 Ubuntu行動規範とパイロン行動規範に大きく基づいています。

思いやりがある

あなたの作品は他の人に使われ、あなたは他の人の作品に依存することになります。 あなたが下す決定はユーザーや同僚に影響を及ぼします、そして私たちはあなたが決定をするときにそれらの結果を考慮に入れることを期待します。 当時は明らかではありませんが、Celeryへの貢献は他の人の仕事に影響を与えます。 たとえば、リリース中にコード、インフラストラクチャ、ポリシー、ドキュメント、および翻訳を変更すると、他の人の作業に悪影響を与える可能性があります。


敬意を表する

セロリコミュニティとそのメンバーは、お互いに敬意を持って接しています。 誰もがセロリに貴重な貢献をすることができます。 私たちは常に同意するとは限りませんが、意見の不一致は悪い行動や悪いマナーの言い訳にはなりません。 私たちは皆、時々何らかの欲求不満を経験するかもしれませんが、その欲求不満が個人的な攻撃に変わることを許すことはできません。 人々が不快または脅迫されていると感じるコミュニティは、生産的なコミュニティではないことを覚えておくことが重要です。 Celeryコミュニティのメンバーは、他の寄稿者だけでなく、Celeryプロジェクト外の人々やCeleryのユーザーとやり取りする際にも敬意を払うことを期待しています。


協力する

コラボレーションは、Celeryとより大きな自由ソフトウェアコミュニティの中心です。 私たちは常にコラボレーションを受け入れる必要があります。 作業は透過的に行われる必要があり、Celeryからのパッチは、ディストリビューションがリリースされたときだけでなく、作成されたときにコミュニティに返される必要があります。 既存のアップストリームプロジェクトの新しいコードに取り組みたい場合は、少なくともそれらのプロジェクトにアイデアと進捗状況を知らせてください。 アイデアの正しい実装について上流から、あるいは同僚からもコンセンサスを得ることができない場合が多いので、始める前にその合意を得る義務を感じないでください。ただし、少なくとも外の世界にあなたの仕事を知らせてください。部外者があなたの努力をテストし、議論し、貢献できるような方法であなたの作品を公開します。


同意しない場合は、他の人に相談してください

政治的および技術的な意見の不一致は常に発生しており、Celeryコミュニティも例外ではありません。 コミュニティとコミュニティプロセスの助けを借りて、意見の不一致や異なる見解を建設的に解決することが重要です。 本当に別の方法で行きたい場合は、可能な限り共通のコアを利用するために行った作業に基づいて、派生ディストリビューションまたはパッケージの代替セットを作成することをお勧めします。


よくわからないときは、助けを求めてください

誰もすべてを知っているわけではなく、完璧であると期待される人もいません。 質問をすることで、将来の多くの問題を回避できるため、質問をすることをお勧めします。 質問された人は、敏感で親切でなければなりません。 ただし、質問をするときは、適切なフォーラムで質問するように注意する必要があります。


慎重に降りる

すべてのプロジェクトの開発者が行き来し、Celeryも例外ではありません。 プロジェクトの全部または一部を離れたり、プロジェクトから離れたりする場合は、プロジェクトの中断を最小限に抑える方法で行うようお願いします。 これは、あなたが去る人にあなたが去ることを伝え、あなたが中断したところから他の人が拾うことができるように適切な措置をとるべきであることを意味します。


バグの報告

安全

セキュリティ関連の問題、脆弱性、または機密情報を含むバグをバグトラッカーやその他の公共の場所に報告しないでください。 代わりに、機密性の高いバグを[email protected]に電子メールで送信する必要があります。

暗号化された情報を送信する場合、PGPキーは次のとおりです。 

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.15 (Darwin)

mQENBFJpWDkBCADFIc9/Fpgse4owLNvsTC7GYfnJL19XO0hnL99sPx+DPbfr+cSE
9wiU+Wp2TfUX7pCLEGrODiEP6ZCZbgtiPgId+JYvMxpP6GXbjiIlHRw1EQNH8RlX
cVxy3rQfVv8PGGiJuyBBjxzvETHW25htVAZ5TI1+CkxmuyyEYqgZN2fNd0wEU19D
+c10G1gSECbCQTCbacLSzdpngAt1Gkrc96r7wGHBBSvDaGDD2pFSkVuTLMbIRrVp
lnKOPMsUijiip2EMr2DvfuXiUIUvaqInTPNWkDynLoh69ib5xC19CSVLONjkKBsr
Pe+qAY29liBatatpXsydY7GIUzyBT3MzgMJlABEBAAG0MUNlbGVyeSBTZWN1cml0
eSBUZWFtIDxzZWN1cml0eUBjZWxlcnlwcm9qZWN0Lm9yZz6JATgEEwECACIFAlJp
WDkCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEOArFOUDCicIw1IH/26f
CViDC7/P13jr+srRdjAsWvQztia9HmTlY8cUnbmkR9w6b6j3F2ayw8VhkyFWgYEJ
wtPBv8mHKADiVSFARS+0yGsfCkia5wDSQuIv6XqRlIrXUyqJbmF4NUFTyCZYoh+C
ZiQpN9xGhFPr5QDlMx2izWg1rvWlG1jY2Es1v/xED3AeCOB1eUGvRe/uJHKjGv7J
rj0pFcptZX+WDF22AN235WYwgJM6TrNfSu8sv8vNAQOVnsKcgsqhuwomSGsOfMQj
LFzIn95MKBBU1G5wOs7JtwiV9jefGqJGBO2FAvOVbvPdK/saSnB+7K36dQcIHqms
5hU4Xj0RIJiod5idlRC5AQ0EUmlYOQEIAJs8OwHMkrdcvy9kk2HBVbdqhgAREMKy
gmphDp7prRL9FqSY/dKpCbG0u82zyJypdb7QiaQ5pfPzPpQcd2dIcohkkh7G3E+e
hS2L9AXHpwR26/PzMBXyr2iNnNc4vTksHvGVDxzFnRpka6vbI/hrrZmYNYh9EAiv
uhE54b3/XhXwFgHjZXb9i8hgJ3nsO0pRwvUAM1bRGMbvf8e9F+kqgV0yWYNnh6QL
4Vpl1+epqp2RKPHyNQftbQyrAHXT9kQF9pPlx013MKYaFTADscuAp4T3dy7xmiwS
crqMbZLzfrxfFOsNxTUGE5vmJCcm+mybAtRo4aV6ACohAO9NevMx8pUAEQEAAYkB
HwQYAQIACQUCUmlYOQIbDAAKCRDgKxTlAwonCNFbB/9esir/f7TufE+isNqErzR/
aZKZo2WzZR9c75kbqo6J6DYuUHe6xI0OZ2qZ60iABDEZAiNXGulysFLCiPdatQ8x
8zt3DF9BMkEck54ZvAjpNSern6zfZb1jPYWZq3TKxlTs/GuCgBAuV4i5vDTZ7xK/
aF+OFY5zN7ciZHkqLgMiTZ+RhqRcK6FhVBP/Y7d9NlBOcDBTxxE1ZO1ute6n7guJ
ciw4hfoRk8qNN19szZuq3UU64zpkM2sBsIFM9tGF2FADRxiOaOWZHmIyVZriPFqW
RUwjSjs7jBVNq0Vy4fCu/5+e+XLOUBOoqtM5W7ELt0t1w9tXebtPEetV86in8fU2
=0chn
-----END PGP PUBLIC KEY BLOCK-----

その他のバグ

バグはいつでもメーリングリストに説明できますが、問題を報告し、タイムリーな対応を確保するための最良の方法は、問題追跡システムを使用することです。

  1. GitHubアカウントを作成します。

新しい問題を作成してディスカッションに参加するには、 GitHubアカウントを作成する必要があります。

  1. バグが本当にバグであるかどうかを判断します。

サポートをリクエストしている場合は、バグを報告しないでください。 そのためには、メーリングリストまたは IRC を使用できます。 それでもサポートが必要な場合は、githubの問題を開くことができます。タイトルの前に、[QUESTION]を付けてください。

  1. バグがまだ報告されていないことを確認してください。

適切なIssueTrackerを検索します。 あなたのようなバグが見つかった場合は、開発者がバグを修正するのに役立つ新しい情報が報告されているかどうかを確認してください。

  1. 最新バージョンを使用しているかどうかを確認してください。

バグは、他のいくつかの改善と修正によって修正される可能性があります-バグトラッカーに既存のレポートがない可能性があります。 セロリ、ビリヤード、昆布、amqp、つるの最新リリースを使用していることを確認してください。

  1. バグに関する情報を収集します。

バグが修正される可能性を最大限に高めるには、バグの原因となった状態を簡単に再現できる必要があります。 ほとんどの場合、この情報はPythonトレースバックメッセージからのものですが、Webサイト/ドキュメント/コードのデザイン、スペル、またはその他のエラーにバグがある可能性があります。

  1. エラーがPythonトレースバックによるものである場合は、バグレポートに含めてください。

  2. また、実行しているプラットフォーム（Windows、macOS、Linuxなど）、Pythonインタープリターのバージョン、Celeryのバージョン、およびバグが発生したときに実行していた関連パッケージを知る必要があります。

  3. 競合状態またはデッドロックを報告している場合、トレースバックを取得するのが難しいか、それほど役に立たない可能性があります。 プロセスを調べて、より多くの診断データを取得してみてください。 いくつかのアイデア：

  4. celery report コマンドからの出力を含めます。

    $ celery -A proj report

    これには構成設定も含まれ、機密性が高いことがわかっているキーの値を削除しようとしますが、APIトークンや認証クレデンシャルなどの機密情報が含まれないように、送信する前に情報も確認してください。

  5. 問題はテストケースが必要としてタグ付けされている可能性があります。 テストケースは、問題が報告している内容を再現するために必要なすべての詳細を表します。 テストケースは、問題を再現する最小限のコード、またはその問題を再現する詳細な手順と構成値にすることができます。


  1. バグを送信してください。

デフォルトでは、 GitHub からメールが届き、バグに新しいコメントが追加されたときに通知されます。 この機能をオフにした場合は、バグを修正しようとしている開発者が尋ねる可能性のある質問を見逃さないように、時々チェックする必要があります。


課題追跡システム

Celeryエコシステムのパッケージのバグは、関連する課題追跡システムに報告する必要があります。

バグの原因がわからない場合は、メーリングリストに問い合わせるか、Celery課題追跡システムを使用してください。


コードベースへの貢献者ガイド

コードベースやスタイルガイドの詳細など、内部の詳細については別のセクションがあります。

詳細については、コードの寄稿者ガイドをお読みください。


バージョン

バージョン番号は、メジャーバージョン、マイナーバージョン、およびリリース番号で構成されます。 バージョン2.1.0以降、SemVerで説明されているバージョン管理セマンティクスを使用しています： http://semver.org 。

安定したリリースはPyPIで公開されていますが、開発リリースはGitHubgitリポジトリでタグとしてのみ利用できます。 すべてのバージョンタグは「v」で始まるため、バージョン0.8.0にはタグv0.8.0があります。


ブランチ

現在アクティブなバージョンのブランチ：

変更ログを見ると、ブランチの状態を確認できます。

ブランチが活発に開発されている場合、最上位のバージョン情報には次のようなメタデータが含まれている必要があります。 

4.3.0
======
:release-date: TBA
:status: DEVELOPMENT
:branch: dev (git calls this master)

statusフィールドは次のいずれかになります。

  • PLANNING

    ブランチは現在実験中であり、計画段階にあります。

  • DEVELOPMENT

    ブランチは活発に開発されていますが、テストスイートは合格であり、製品は機能しており、ユーザーがテストできる必要があります。

  • FROZEN

    ブランチは凍結されており、これ以上の機能は受け入れられません。 ブランチがフリーズすると、リリースされる前に可能な限りバージョンをテストすることに重点が置かれます。

開発ブランチ

devブランチ（gitでは「マスター」と呼ばれます）は、次のバージョンの開発が行われる場所です。


メンテナンスブランチ

メンテナンスブランチの名前はバージョンにちなんで付けられています。たとえば、2.2.xシリーズのメンテナンスブランチの名前は2.2です。

以前は、これらはreleaseXX-maintという名前でした。

現在維持しているバージョンは次のとおりです。

  • 4.2

    これが現在のシリーズです。

  • 4.1

    Python2.6のサポートを終了します。 Python 3.4、3.5、および3.6のサポートを追加します。

  • 3.1

    Python 2.6、2.7、3.3の公式サポートであり、PyPyでもサポートされています。


アーカイブされたブランチ

アーカイブされたブランチは履歴を保存するためだけに保持され、理論的には、公式にサポートされなくなったシリーズに依存している場合、誰かがこれらのパッチを提供できます。

アーカイブされたバージョンの名前はX.Y-archivedです。

よりクリーンな履歴を維持し、互換性を削除してプロジェクトを継続的に改善するために、現在アーカイブバージョンはありません。


機能ブランチ

主要な新機能は、専用のブランチで作業されています。 これらのブランチには厳密な命名要件はありません。

機能ブランチは、リリースブランチにマージされると削除されます。


タグ

  • タグは、リリースのタグ付けにのみ使用されます。 リリースタグには、vX.Y.Zの形式で名前が付けられます（例：v2.3.1）。
  • 実験的なリリースには、追加の識別子vX.Y.Z-idが含まれています（例：v3.0.0-rc1）。
  • 実験的なタグは、公式リリース後に削除される可能性があります。


機能とパッチに取り組んでいます

ノート

セロリへの貢献は可能な限り単純でなければならないので、これらのステップのどれも必須と見なされるべきではありません。

それがあなたの好みの作業方法であるならば、あなたは電子メールでパッチを送ることさえできます。 私たちはあなたをこれ以上好きではありません、あなたがするどんな貢献も常に感謝されます！

ただし、これらの手順に従うと、メンテナの作業が楽になり、変更がより早く受け入れられる可能性があります。


リポジトリのフォークと設定

まず、Celeryリポジトリをフォークする必要があります。 これについての良い紹介は、GitHubガイド： Fork a Repo にあります。

リポジトリのクローンを作成したら、コピーをマシン上のディレクトリにチェックアウトする必要があります。 

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

リポジトリのクローンが作成されたら、ディレクトリに入り、アップストリームの変更に簡単にアクセスできるように設定します。 

$ cd celery
$ git remote add upstream git://github.com/celery/celery.git
$ git fetch upstream

アップストリームから新しい変更を取り込む必要がある場合は、常に--rebaseオプションをgit pullに使用する必要があります。 

git pull --rebase upstream master

このオプションを使用すると、コミットノートをマージして履歴を乱雑にすることはありません。 git でのマージコミットのリベースを参照してください。 リベースについて詳しく知りたい場合は、GitHubガイドの Rebase セクションを参照してください。

gitがmasterを呼び出すのとは別のブランチで作業する必要がある場合は、次のようにリモートブランチをフェッチしてチェックアウトできます。 

git checkout --track -b 5.0-devel upstream/5.0-devel

注：機能または修正ブランチはupstream/masterから作成する必要があります。


Dockerを使用した開発とテスト

ブローカーやバックエンドなど、Celeryの多くのコンポーネントがあるため、 Docker および docker-compose を利用して、開発とテストのサイクルを大幅に簡素化できます。 ここでのDocker構成には、少なくとも17.13.0のDockerバージョンと docker-compose 1.13.0+が必要です。

Dockerコンポーネントはdocker/フォルダー内にあり、Dockerイメージは次の方法でビルドできます。 

$ docker-compose build celery

経由して実行します： 

$ docker-compose run --rm celery <command>

どこ Dockerコンテナで実行するコマンドです。 –rm フラグは、コンテナーが終了した後に削除する必要があることを示し、不要なコンテナーの蓄積を防ぐのに役立ちます。

実行するいくつかの便利なコマンド：

  • bash

    通常のシェルのようにDockerコンテナに入るには

  • make test

    テストスイートを実行します。 注：これは、デフォルトでpython3.8を使用してテストを実行します。

  • tox

    toxを実行し、さまざまな構成に対してテストします。 注：このコマンドは、tox.iniで定義されているすべての環境に対してテストを実行します。 しばらく時間がかかります。

  • pyenv exec python{3.6,3.7,3.8,3.9} -m pytest t/unit

    pytestを使用して単体テストを実行します。

    ノート： {3.6,3.7,3.8,3.9} means you can use any of those options. e.g. pyenv exec python3.7 -m pytest t/unit

  • pyenv exec python{3.6,3.7,3.8,3.9} -m pytest t/integration

    pytestを使用して統合テストを実行するには

    ノート： {3.6,3.7,3.8,3.9} means you can use any of those options. e.g. pyenv exec python3.7 -m pytest t/unit

デフォルトでは、docker-composeはCeleryフォルダーとテストフォルダーをDockerコンテナーにマウントし、コードの変更とテストをDockerコンテナー内ですぐに表示できるようにします。 使用するブローカーやバックエンドなどの環境変数もdocker/docker-compose.ymlファイルで定義されています。

docker-compose build celeryを実行すると、celery/celery:devという名前のイメージが作成されます。 このDockerイメージには、開発に必要なすべての依存関係がインストールされています。 pyenvは複数のPythonバージョンをインストールするために使用され、DockerイメージはPython 3.6、3.7、3.8、および3.9を提供します。 デフォルトのPythonバージョンは3.8に設定されています。

docker-compose.ymlファイルは、統合テストを実行するために必要な環境変数を定義します。 celeryサービスもコードベースをマウントし、PYTHONPATH環境変数を/home/developer/celeryに設定します。 PYTHONPATHを設定することにより、サービスはマウントされたコードベースを開発用のグローバルモジュールとして使用できるようにします。 必要に応じて、python -m pip install -e .を実行して、コードベースを開発モードでインストールすることもできます。

Djangoまたはスタンドアロンプロジェクトを実行して機能を手動でテストまたはデバッグする場合は、 docker-compose で作成されたイメージを使用して、カスタムコードをマウントできます。 次に例を示します。

次のようなフォルダ構造を想定しています。 

+ celery_project
  + celery # repository cloned here.
  + my_project
    - manage.py
    + my_project
      - views.py
version: "3"

services:
    celery:
        image: celery/celery:dev
        environment:
            TEST_BROKER: amqp://rabbit:5672
            TEST_BACKEND: redis://redis
         volumes:
             - ../../celery:/home/developer/celery
             - ../my_project:/home/developer/my_project
         depends_on:
             - rabbit
             - redis
     rabbit:
         image: rabbitmq:latest
     redis:
         image: redis:latest

前の例では、このリポジトリからビルドできるイメージを使用し、セロリコードベースとカスタムプロジェクトをマウントしています。


ユニットテストスイートの実行

仮想環境を使用して、またはDockerのすぐ外で開発する場合は、必要なすべての依存関係がインストールされていることを確認する必要があります。 すべての依存関係を簡単にインストールできるようにするために、複数の要件ファイルがあります。 すべての要件ファイルを使用する必要はありませんが、 default.txt を使用する必要があります。 

# pip install -U -r requirements/default.txt

Celeryテストスイートを実行するには、requirements/test.txtをインストールする必要があります。 

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

必要な依存関係をインストールした後、を呼び出すことでテストスイートを実行できます ：pypi： `pytest ` ： 

$ pytest t/unit
$ pytest t/integration

pytest の便利なオプションは次のとおりです。

  • -x

    失敗した最初のテストでテストの実行を停止します。

  • -s

    出力をキャプチャしない

  • -v

    詳細な出力で実行します。

単一のテストファイルに対してのみテストを実行する場合は、次のように実行できます。 

$ pytest t/unit/worker/test_worker.py

テストカバレッジの計算

テストカバレッジを計算するには、最初に：pypi： `pytest-cov` モジュールをインストールする必要があります。

：pypi： `pytest-cov` モジュールのインストール： 

$ pip install -U pytest-cov
HTML形式のコードカバレッジ

  1. --cov-report=html引数を有効にして pytest を実行します。

    $ pytest --cov=celery --cov-report=html

  2. カバレッジ出力は、htmlcov/ディレクトリに配置されます。

    $ open htmlcov/index.html


XMLでのコードカバレッジ（Coberturaスタイル）
  1. --cov-report=xml引数を有効にして pytest を実行します。
$ pytest --cov=celery --cov-report=xml
  1. カバレッジXML出力は、coverage.xmlファイルに配置されます。


サポートされているすべてのPythonバージョンでテストを実行する

ディストリビューションのトップディレクトリに：pypi： `tox` 構成ファイルがあります。

サポートされているすべてのPythonバージョンのテストを実行するには、次のコマンドを実行するだけです。 

$ tox

特定のPythonバージョンのみをテストする場合は、tox -eオプションを使用します。 

$ tox -e 3.7

ドキュメントの作成

ドキュメントを作成するには、requirements/docs.txtおよびrequirements/default.txtにリストされている依存関係をインストールする必要があります。 

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

さらに、警告なしでビルドするには、次のパッケージをインストールする必要があります。 

$ apt-get install texlive texlive-latex-extra dvipng

これらの依存関係をインストールすると、次のコマンドを実行してドキュメントを作成できるようになります。 

$ cd docs
$ rm -rf _build
$ make html

ビルド出力にエラーや警告がないことを確認してください。 ビルドが成功すると、ドキュメントは_build/htmlで入手できます。


Dockerを使用してドキュメントを作成する

次のコマンドを実行してドキュメントを作成します。 

$ docker-compose -f docker/docker-compose.yml up --build docs

このサービスは、:7000でローカルドキュメントサーバーを起動します。 サーバーは--watchオプションを有効にしてsphinx-autobuildを使用しているため、ドキュメントをライブ編集できます。 docker/docker-compose.ymlの追加のオプションと構成を確認してください


あなたの貢献を確認する

これらのツールを使用するには、いくつかの依存関係をインストールする必要があります。 これらの依存関係はrequirements/pkgutils.txtにあります。

依存関係のインストール： 

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

pyflakes＆PEP-8

変更が PEP 8 に準拠していることを確認し、pyflakesを実行するには、次のコマンドを実行します。 

$ make flakecheck

このコマンドが失敗したときに負の終了コードを返さないようにするには、代わりにflakesターゲットを使用します。 

$ make flakes

APIリファレンス

すべてのモジュールのAPIリファレンスに対応するセクションがあることを確認するには、以下を実行してください。 

$ make apicheck

ファイルが欠落している場合は、既存の参照ファイルをコピーして追加できます。

モジュールが内部にある場合は、docs/internals/reference/にある内部参照の一部である必要があります。 モジュールが公開されている場合は、docs/reference/に配置する必要があります。

たとえば、モジュールcelery.worker.awesomeの参照がなく、このモジュールがパブリックAPIの一部と見なされる場合は、次の手順を使用します。

既存のファイルをテンプレートとして使用します。 

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

お気に入りのエディターを使用してファイルを編集します。 

$ vim celery.worker.awesome.rst

    # change every occurrence of ``celery.schedules`` to
    # ``celery.worker.awesome``

お気に入りのエディターを使用してインデックスを編集します。 

$ vim index.rst

    # Add ``celery.worker.awesome`` to the index.

変更をコミットします。 

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

Isort

Isort は、インポートをアルファベット順に並べ替えてセクションに分割するのに役立つPythonユーティリティです。 Celeryプロジェクトは、isortを使用して、すべてのモジュールのインポートをより適切に維持します。 新しいモジュールがある場合、または既存のモジュールのインポートを変更する必要がある場合は、isortを実行してください。 

$ isort my_module.py # Run isort for one file
$ isort -rc . # Run it recursively
$ isort m_module.py --diff # Do a dry-run to see the proposed changes

プルリクエストの作成

機能/バグ修正が完了したら、プルリクエストを送信して、メンテナが確認できるようにすることをお勧めします。

プルリクエストを送信する前に、このチェックリストに目を通し、メンテナが提案された変更を簡単に受け入れられるようにしてください。

  • []変更や新機能にユニットテストや統合テストがあることを確認してください。

    テストが書かれていない場合は、Needs Test Coverageという名前のラベルがPRに割り当てられます。

  • []ユニットテストカバレッジが減少しないことを確認してください。

    pytest -xv --cov=celery --cov-report=xml --cov-report term。 現在のテストカバレッジはここで確認できます： https://codecov.io/gh/celery/celery

  • []コードに対してpre-commitを実行します。 次のコマンドは有効です

    および同等のもの。：

    $ pre-commit run --all-files
$ tox -e lint
  • []すべてがOKであることを確認するためにAPIドキュメントを作成します。 次のコマンドは有効です

    および同等のもの。：

    $ make apicheck
$ cd docs && sphinx-build -b apicheck -d _build/doctrees . _build/apicheck
$ tox -e apicheck
  • [] configcheckをビルドします。 次のコマンドは有効です

    および同等のもの。：

    $ make configcheck
$ cd docs && sphinx-build -b configcheck -d _build/doctrees   . _build/configcheck
$ tox -e configcheck
  • [] banditを実行して、セキュリティの問題がないことを確認します。 次のコマンドは有効です

    および同等のもの。：

    $ pip install -U bandit
$ bandit -b bandit.json celery/
$ tox -e bandit
  • []すべてのPythonバージョンに対してユニットテストと統合テストを実行します。 次のコマンドは有効です

    および同等のもの。：

    $ tox -v

  • []新規または変更されたインポートでisortを確認します。

    $ isort my_module.py --diff

プルリクエストの作成は簡単で、投稿の進行状況を追跡することもできます。 これがどのように行われるかについては、GitHubガイドのプルリクエストセクションをお読みください。

ここに概説されている手順に従って、既存の問題にプルリクエストを添付することもできます： https://bit.ly/koJoso

ハブを使用してプルリクエストを作成することもできます。 例： https://theiconic.tech/git-hub-fbe2e13ef4d1

ステータスラベル

githubの問題とPRを簡単に管理するために使用されるさまざまなラベルがあります。 これらのラベルのほとんどは、重要な詳細で各問題を簡単に分類できるようにします。 たとえば、問題やPRにComponent:canvasラベルが表示される場合があります。 Component:canvasラベルは、問題またはPRがキャンバス機能に対応していることを意味します。 これらのラベルはメンテナによって設定され、ほとんどの場合、外部の貢献者はそれらについて心配する必要はありません。 これらのラベルのサブセットには、 Status：が付加されます。 通常、 Status：ラベルは、問題またはPRに必要な重要なアクションを示します。 このようなステータスの概要は次のとおりです。

  • 状態：再現できません

    1人以上のCeleryコアチームメンバーが問題を再現できませんでした。

  • ステータス：確認済み

    問題またはPRは、1人以上のCeleryコアチームメンバーによって確認されています。

  • ステータス：重複

    重複する問題またはPR。

  • ステータス：フィードバックが必要

    1人以上のCeleryコアチームメンバーが、問題またはPRに関するフィードバックを求めています。

  • ステータス：テストケースあり

    問題が確認されているか、PRにテストケースが含まれています。 これは、新機能やバグ修正のテストを正しく作成するために特に重要です。

  • ステータス：進行中

    PRはまだ進行中です。

  • ステータス：無効

    報告された問題またはPRはプロジェクトに対して無効です。

  • ステータス：ドキュメントが必要

    PRには、提案された機能またはバグ修正に関するドキュメントは含まれていません。

  • ステータス：リベースが必要

    PRはmasterでリベースされていません。 マージの競合を解決するには、PRをmasterにマージする前に、PRをリベースすることが非常に重要です。

  • ステータス：テストカバレッジが必要

    Celeryは、 codecov を使用してコードカバレッジを確認します。 PRがコードカバレッジを低下させないことを確認してください。 このラベルは、コードカバレッジが必要なPRを識別します。

  • ステータス：テストケースが必要

    問題またはPRにはテストケースが必要です。 テストケースは、問題を再現する最小限のコードスニペット、または報告された問題を再現する詳細な手順と構成値のセットにすることができます。 可能であれば、テストケースをPRの形でCeleryの統合スイートに提出できます。 バグが修正されるまで、テストケースは失敗としてマークされます。 Celeryの統合スイートでテストケースを実行できない場合は、問題自体に説明することをお勧めします。

  • ステータス：検証が必要

    このラベルは、レポーターによって提供されたテストケースを確認する必要があること、および/または統合スイートにテストを含める必要があることを他のユーザーに通知するために使用されます。

  • ステータス：バグではありません

    報告された問題はバグではないと判断されました。

  • ステータス：修正されません

    この問題は修正されないことが決定されました。 悲しいことに、Celeryプロジェクトには無制限のリソースがなく、この決定を下さなければならない場合があります。 ただし、問題やPRにStatus: Won't Fixのラベルが付いている場合でも、外部の貢献者は誰でも助けてくれるように招待されています。

  • ステータス：Works For Me

    1人以上のCeleryコアチームメンバーが、報告された問題が彼らのために機能することを確認しました。


コーディングスタイル

おそらく周囲のコードからコーディングスタイルを選択できるはずですが、次の規則に注意することをお勧めします。

  • すべてのPythonコードは、 PEP 8 ガイドラインに従う必要があります。

：pypi： `pep8` は、コードが規則に従っていることを確認するために使用できるユーティリティです。

  • Docstringは、 PEP 257 の規則に従い、次のスタイルを使用する必要があります。

    これを行う：

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

    More details.

    """

    また：

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

    しかし、これではありません：

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

  • 行は78列を超えてはなりません。

    textwidthオプションを設定することで、 vim でこれを強制できます。

    set textwidth=78

    この制限を順守するとコードが読みにくくなる場合は、あと1文字追加する必要があります。 これは、78がソフト制限であり、79がハード制限であることを意味します:)

  • 輸入注文

    • Python標準ライブラリ（ import xxx ）

    • Python標準ライブラリ（ from xxx import ）

    • サードパーティのパッケージ。

    • 現在のパッケージの他のモジュール。

    またはDjangoを使用するコードの場合：

    • Python標準ライブラリ（ import xxx ）

    • Python標準ライブラリ（ from xxx import ）

    • サードパーティのパッケージ。

    • Djangoパッケージ。

    • 現在のパッケージの他のモジュール。

    これらのセクション内で、インポートはモジュール名でソートする必要があります。

    例：

    import threading
import time

from collections import deque
from Queue import Queue, Empty

from .platforms import Pidfile
from .utils.time import maybe_timedelta

  • ワイルドカードインポートは使用しないでください（ from xxx import * ）。

  • Python 2.5が最も古いサポートバージョンであるディストリビューションの場合、追加のルールが適用されます。

    • 絶対インポートは、すべてのモジュールの上部で有効にする必要があります。

      from __future__ import absolute_import

    • モジュールがwithステートメントを使用し、Python 2.5と互換性がある必要がある場合（セロリは互換性がありません）、次のことも有効にする必要があります。

      from __future__ import with_statement

    • 古いPython2.5リリースは、同じ将来のインポート行での複数の機能のインポートをサポートしていなかったため、将来のすべてのインポートは独自の行にある必要があります。

      # Good
from __future__ import absolute_import
from __future__ import with_statement

# Bad
from __future__ import absolute_import, with_statement

    （パッケージにPython 2.5のサポートが含まれていない場合、このルールは適用されないことに注意してください）

  • ディストリビューションが2.5未満のPythonバージョンをサポートしていない場合は、「新しいスタイル」の相対インポートを使用することに注意してください。

    これにはPython2.5以降が必要です。

    from . import submodule


追加のライブラリを必要とする貢献機能

新しい結果バックエンドなどの一部の機能では、ユーザーがインストールする必要のある追加のライブラリが必要になる場合があります。

これにはsetuptools extra_requires を使用し、サードパーティのライブラリを必要とするすべての新しいオプション機能を追加する必要があります。

  1. Requirements / extras に新しい要件ファイルを追加します

    Cassandraバックエンドの場合、これはrequirements/extras/cassandra.txtであり、ファイルは次のようになります。

    pycassa

    これらはpip要件ファイルであるため、バージョン指定子を設定でき、複数のパッケージを改行で区切ることができます。 より複雑な例は次のとおりです。

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

  2. setup.pyを変更します

    要件ファイルを追加したら、extras_requireセクションのsetup.pyにオプションとして追加する必要があります。

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

  3. docs/includes/installation.txtで新機能を文書化する

    docs/includes/installation.txtのバンドルセクションのリストに機能を追加する必要があります。

    このファイルに変更を加えた後、ディストリビューションREADMEファイルをレンダリングする必要があります。

    $ pip install -U requirements/pkgutils.txt
$ make readme

実行する必要があるのはこれだけですが、機能で構成オプションを追加する場合は、docs/configuration.rstに文書化する必要があることに注意してください。 また、すべての設定をcelery/app/defaults.pyモジュールに追加する必要があります。

結果のバックエンドには、docs/configuration.rstファイルに別のセクションが必要です。


連絡先

これは、公式のgitリポジトリ、PyPIパッケージに関する質問について連絡できる人のリストです。ドキュメントのページを読んでください。

問題が緊急ではない場合は、問題を報告することをお勧めします。

コミッター

ソレムに聞く

github
https://github.com/ask
ツイッター
https://twitter.com/#!/asksol


Asif Saif Uddin

github
https://github.com/auvipy
ツイッター
https://twitter.com/#!/auvipy


ドミトリー・マリノフスキー

github
https://github.com/malinoff
ツイッター
https://twitter.com/__malinoff__


IonelCristianMărieș

github
https://github.com/ionelmc
ツイッター
https://twitter.com/ionelmc


Mher Movsisyan

github
https://github.com/mher
ツイッター
https://twitter.com/#!/movsm


オメル・カッツ

github
https://github.com/thedrow
ツイッター
https://twitter.com/the_drow


スティーブ・モーリン

github
https://github.com/steeve
ツイッター
https://twitter.com/#!/steeve


Josue Balandrano Coronel

github
https://github.com/xirdneh
ツイッター
https://twitter.com/eusoj_xirdneh


Webサイト

セロリプロジェクトのウェブサイトは、によって運営および維持されています

マウロロッコ

github
https://github.com/fireantology
ツイッター
https://twitter.com/#!/fireantology

設計者：


Jan Henrik Helmers

ウェブ
http://www.helmersworks.com
ツイッター
https://twitter.com/#!/helmers


パッケージ

billiard

最終的にPythonstdlibにマージされる改善を含むマルチプロセッシングのフォーク。

ギット
https://github.com/celery/billiard
CI
https://travis-ci.org/#!/celery/billiard/
Windows-CI
https://ci.appveyor.com/project/ask/billiard
PyPI
：pypi： `ビリヤード`


django-celery-beat

DjangoORMを使用した管理インターフェースを備えたデータベースに裏打ちされた定期的なタスク。

ギット
https://github.com/celery/django-celery-beat
CI
https://travis-ci.org/#!/celery/django-celery-beat
Windows-CI
https://ci.appveyor.com/project/ask/django-celery-beat
PyPI
：pypi： `django-celery-beat`


django-celery-results

タスクの結果をDjangoORMに保存するか、Django CacheFrameworkを使用します。

ギット
https://github.com/celery/django-celery-results
CI
https://travis-ci.org/#!/celery/django-celery-results
Windows-CI
https://ci.appveyor.com/project/ask/django-celery-results
PyPI
：pypi： `django-celery-results`


librabbitmq

Cで記述された非常に高速なPythonAMQPクライアント。

ギット
https://github.com/celery/librabbitmq
PyPI
：pypi： `librabbitmq`


cell

アクターライブラリ。

ギット
https://github.com/celery/cell
PyPI
：pypi： `cell`


cyme

分散セロリインスタンスマネージャー。

ギット
https://github.com/celery/cyme
PyPI
：pypi： `cyme`
ドキュメント
https://cyme.readthedocs.io/


リリース手順

バージョン番号の更新

バージョン番号は、次の3か所で更新する必要があります。

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


以前のファイルへの変更は、[バンプバージョンコマンドラインツール]（ https://pypi.org/project/bumpversion/）で処理できます。 対応する構成は.bumpversion.cfgにあります。 必要な変更を行うには、次を実行します。 

$ bumpversion

これらのファイルを変更した後、READMEファイルをレンダリングする必要があります。 sphinx構文を一般的なreStructuredText構文に変換するスクリプトがあり、make target readme がこれを行います。 

$ make readme

次に、変更をコミットします。 

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

新しいバージョンタグを作成します。 

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

リリース

新しいパブリック安定リリースを作成するコマンド： 

$ make distcheck  # checks pep8, autodoc index, runs tests and more
$ make dist  # NOTE: Runs git clean -xdf and removes files not in the repo.
$ python setup.py sdist upload --sign --identity='Celery Security Team'
$ python setup.py bdist_wheel upload --sign --identity='Celery Security Team'

これが新しいリリースシリーズである場合は、次のことも行う必要があります。

  • 次の場所にあるReadTheDocs管理インターフェイスに移動します。

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

  • 「プロジェクトの編集」と入力します

    デフォルトのブランチをこのシリーズのブランチに変更します。たとえば、2.4シリーズには2.4ブランチを使用します。

  • また、「バージョン」タブで以前のバージョンを追加します。



「https://www.finddevguides.com/index.php?title=Celery/docs/latest/contributing&oldid=94314」から取得
Powered by MediaWiki