Define the top-level public API and deprecate redundant exports
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 35/100
- issue の種類
- リファクタリング
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- python
調査の方向性
Start with py/src/braintrust/__init__.py and the existing public export coverage in type_tests/test_public_exports.py; read the export definitions in workflow_eval.py and supporting modules named in the issue. Inventory retained exports, deprecated aliases with exact replacements, and implementation spillover, then establish canonical imports and compatibility warnings. Done means the explicit root API and __all__, migration guidance, runtime and type coverage, updated imports, and optional-provider behavior meet the acceptance criteria.
索引モデルが issue の本文から書いたものです。
説明
Problem
The top-level braintrust namespace mixes primary SDK entry points, supporting types, specialized features, and implementation details. py/src/braintrust/__init__.py uses wildcard imports and has no package-level __all__. A fresh import in the inspected checkout exposed 490 non-underscore names, including imported libraries and submodules; that count describes the observed namespace, not an intentional public contract.
Examples of spillover include DiskCache, LogQueue, ProjectIdCache, global_, construct_logs3_data, os, json, Any, cast, tee, and SSEClient.
Import order also determines the meaning of several names. Project, Dataset, Experiment, and Prompt ultimately resolve to classes from logger.py, replacing earlier exports. In particular, braintrust.Project is a different class from the project returned by braintrust.projects.create().
We should define an explicit top-level API, deprecate selected existing import paths with clear replacements, and stop exposing implementation imports as part of the intended contract.
Proposed top-level API
Keep the entry points for common workflows:
| Workflow | Top-level exports |
|---|---|
| Evaluations | Eval, EvalAsync |
| Resource initialization | init, init_dataset, init_logger |
| Authentication | login |
| Tracing | traced, start_span, current_span, flush |
| Instrumentation | auto_instrument |
| Prompts and parameters | load_prompt, load_prompt_async, load_parameters |
| Hosted function invocation | invoke, invoke_async |
| Authoring and publishing | projects |
| Workflow evaluations | define_workflow_eval, WorkflowEval, and the existing public workflow task, scorer, submission, batching, store, and result helpers |
Workflow evaluations are a first-class top-level API. Keep the existing 25 names declared in workflow_eval.__all__; they are excluded from the proposed root-import deprecations. This includes the WorkflowTask*, WorkflowScorer*, WorkflowBatch*, WorkflowSubmission*, and WorkflowEval* families.
Supporting types can be imported from stable submodules. This is a focused root API, not a rule that prohibits all classes at the top level: the workflow evaluation family is intentionally retained.
A. Deprecations
Deprecate selected top-level aliases/import paths while retaining their underlying functionality:
| Candidate | Replacement |
|---|---|
init_experiment |
braintrust.init (it is currently an alias) |
Provider-specific wrap_* and setup_* helpers |
braintrust.integrations.<provider> |
BraintrustLogHandler |
braintrust.logs |
| Span customization APIs | braintrust.span_customizer |
| Dataset pipeline APIs | braintrust.dataset_pipeline |
| Sandbox registration APIs | braintrust.sandbox |
| Evaluation support types | braintrust.framework |
| Scoring objects and types | braintrust.score |
| Stream/chunk classes | braintrust.functions.stream |
| Generated schemas | braintrust.generated_types |
| Resource classes, attachments, summaries, and other supporting types | Establish and document stable submodule paths before issuing deprecations |
Do not assume braintrust.types already re-exports every supporting type. Choose permanent destinations before asking users to migrate, and avoid multiple successive import migrations. Resolve the Project ambiguity explicitly in migration guidance.
Treat global log and summarize as a separate decision: replacing them with methods on experiment/logger handles changes usage beyond an import-path migration. Audit their use and decide separately whether to deprecate them. Likewise, audit advanced helpers not covered by the table before making removal decisions.
Compatibility rollout:
- Establish and document canonical submodule imports.
- Update repository examples, documentation, and internal imports to use the intended API.
- Preserve deprecated root imports through compatibility aliases, with
DeprecationWarningmessages naming the exact replacement import. A module__getattr__compatibility layer is one option; avoid eagerly binding aliases if that prevents access warnings. - Remove deprecated aliases in a future breaking release under an explicit deprecation policy.
B. Export cleanup
- Replace wildcard imports in
braintrust/__init__.pywith explicit re-exports. - Add an explicit package-level
__all__for the supported root API, including the workflow evaluation family. - Preserve static type-checker visibility of intended re-exports, including the explicit
asaliasing pattern already covered bytype_tests/test_public_exports.pywhere needed. - Stop eagerly re-exporting third-party imports, typing utilities, internal caches/queues, serialization helpers, and mutable implementation state. Audit compatibility before removing names that downstream users may have adopted.
- Review the three explicitly imported
_internal_*hooks separately; they are private compatibility hooks, not part of the public export list. - Preserve optional-provider lazy loading and existing supported import-time behavior.
__all__ defines the intended public contract and wildcard-import behavior; it does not hide existing attributes or prevent Python from attaching imported submodules to the package. The goal is an explicit supported API, not a guarantee that dir(braintrust) contains only those names.
Acceptance criteria
- Check in an explicit inventory of retained exports, deprecated root aliases with exact replacements, and implementation spillover.
- Add explicit top-level re-exports and
__all__, retaining all existing public workflow evaluation exports. - Document canonical submodule imports and a deprecation/removal policy.
- Add runtime coverage for intended exports, deprecated aliases/warnings, and identity/behavior preservation.
- Extend public-export type tests to cover the retained API and supported replacement imports.
- Update examples and internal imports; verify optional providers remain optional.
- Run the relevant core and type-checking sessions from
py/noxfile.py.
Relevant files: py/src/braintrust/__init__.py, framework.py, framework2.py, logger.py, generated_types.py, workflow_eval.py, and type_tests/test_public_exports.py.
- 主要言語
- Python
- スター
- 22
- フォーク
- 27
- 平均マージ
- 14時間 49分
- マージ済み PR(30日)
- 126
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
braintrustdata/braintrust-sdk-python のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
braintrustdata/braintrust-sdk-python#962 ·
メンテナーはふだん 1 日以内に返信
-
Temporal: add `workflow.Info.original_execution_run_id` to workflow span metadata対応中かも @Ehsan-hash が 1 日前に担当しました。 オープンfeature python
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
braintrustdata/braintrust-sdk-python#868 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 20/100
braintrustdata/braintrust-sdk-python#957 ·
メンテナーはふだん 1 日以内に返信
-
python
braintrustdata/braintrust-sdk-python#839 ·
メンテナーはふだん 1 日以内に返信
-
new-integration
難易度 4/5 3〜5日 初心者へのやさしさ 68/100
braintrustdata/braintrust-sdk-python#808 ·
メンテナーはふだん 1 日以内に返信
braintrustdata/braintrust-sdk-python の issue をすべて見る
似ている issue
-
難易度 1/5 1〜3時間 初心者へのやさしさ 68/100
FavioVazquez/showtime#101 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
rossant/awesome-math#199 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
nautechsystems/nautilus_trader#5365 ·
メンテナーはふだん 1 日以内に返信
-
Examples say cnxオープンdocumentation embedded
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信