temporalio / temporalio/samples-python

[Feature Request] Guide against single-file structure

オープン
#49 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

enhancement
主要言語
Python
スター
367
フォーク
121
平均マージ
3日 20時間
マージ済み PR(30日)
11

説明

Is your feature request related to a problem? Please describe.

Given this single-file pattern of running a Workflow inside a Worker:

https://github.com/temporalio/samples-python/blob/7b3944926c3743bc0dcb3b781d8cc64e0330bac4/hello/hello_activity.py#L47-L64

there is potential (and one past instance I know of) for people learning based off of samples to think that in order to run a Workflow, you need to run it inside an async with Worker. When they try to develop an application based on that paradigm, they run into a number of issues.

Describe the solution you'd like

Make it clear that when developing, we recommend:

  • running a worker separately from workflows
  • defaulting to a single worker for all workflows, not one worker per workflow

We could make it clear by structuring all samples that way. OTOH I like the brevity of the single file samples. Another possibility is changing the comment. The drawbacks to that are:

  • some people don't read comments
  • the comment might not be clear, unless you point to a multi-file sample, what exactly we recommend doing

Comment is currently:

# While the worker is running, use the client to run the workflow and
# print out its result. Note, in many production setups, the client
# would be in a completely separate process from the worker.

Perhaps could be:

# Use the client to run the workflow and print out its result. 
# NOTE: when developing, we recommend starting out running a 
# single worker that has all your workflow and activities and
# running client code in a separate process. See, for example,
# how the encryption sample has a separate files to run:
# worker.py runs the worker and starter.py uses the client.

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

hello/hello_activity.py の47-64行目から始め、単一ファイルでの Worker と workflow の構成を、暗号化サンプルの worker.py および starter.py と比較します。ガイダンスをサンプル構造に含めるべきかコメントに含めるべきかを判断し、そのうえで、1つの Worker が workflows を提供する、分離された Worker プロセスとクライアントプロセスが明確かつ一貫するよう、関連するサンプルを更新します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
python
領域
documentation
issue の種類
ドキュメント
難易度
3/5
見積もり時間
1〜2日
活発さ
停滞
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。