Use lock files and relative dependency cooldowns
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 42/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 領域
- build-system, release
調査の方向性
まず pyproject.toml と tools/configure_macos_env.sh を読み、次に cibuildwheel が現在どのように build 依存関係を取得しているかを確認します。uv と pixi の lockfile アプローチを、依存関係の相対的なクールダウン期間と macOS での libomp の扱いを含めて比較します。build、sdist、test の依存関係が明示的にロックされ、更新が自動化されていれば完了です。
索引モデルが issue の本文から書いたものです。
説明
I think the use of requirements files with X.Y.Z pinned version constraints is good but not enough to ensure full reproducibility of the builds (there can be .post0 markers after the .Z component for instance). I think we should use an explicit lock file to manage:
- the cibuildwheel dependency itself (this will transitively lock the version of cibuildwheel's own dependencies as per the "pinned" policy documented in https://cibuildwheel.pypa.io/en/stable/options/#dependency-versions)
- the sdist build dependencies;
- the test dependencies.
The lockfile(s) should be automatically refreshed, e.g. on a monthly basis with a relative dependency cooldown policy of a week to reduce the exposure of the release process to ongoing OSS Supply Chain attacks.
The lockfile(s) in the release repo could either be managed via uv or pixi. I don't think it matters much because we don't need conda-forge for the build and testing process in this repo. All the Python-level builds dependencies are fetched from pypi.org and the rest come from the system image (e.g. manylinux). EDIT: actually we do fetch a fixed binary for libomp on macOS, so maybe we could use pixi and a lock file to do that more automatically.
When the lock files are updated, we should use relative dependency cooldowns such as uv's exclude-newer config or pixi's exlude-newer config).
Ideally, the build dependencies should also be locked explicitly in the repo as for the other dependencies. According to cibuildwheel's doc, the pip wheel command is used under the hood to setup the build env automatically. By default, it will install dependencies from the pyproject.toml file. However, it should be possible to pass an explicit pylock.toml export of a proper uv managed lockfile to pip wheel -r. Alternatively, we configure cibuildwheel's before-build hook to run a script to explicitly prepare the build environment manually using uv or pixi commands and disable build isolation and run pip wheel --no-build-isolation --no-deps.
- 主要言語
- Shell
- スター
- 2
- フォーク
- 5
- 平均マージ
- 24分
- マージ済み PR（30日）
- 4
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
scikit-learn/scikit-learn-release のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
scikit-learn/scikit-learn-release#7 · コメント 9 件 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
scikit-learn/scikit-learn-release#6 · コメント 1 件 ·
scikit-learn/scikit-learn-release の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
msys2/MINGW-packages#33356 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Misleading 'Update → Config → Hyprland' menu item silently resets user configs without confirmation対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
ekalinin/github-markdown-toc#204 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1〜3時間 初心者へのやさしさ 88/100