bioconda-recipesはCondaチャネル用レシピ集として何を担うか

biocondaチャネルとレシピ集の位置づけ

bioconda-recipesは、Anaconda上の bioconda チャネル向けCondaレシピをホストするリポジトリである。README/README称、LinuxとmacOS向けにx86_64およびaarch64/arm64をサポートするバイオinformatics関連パッケージを提供する。Conda自体はプラットフォームと言語に依存しないパッケージマネージャーだが、このリポジトリのスコープはバイオinformaticsに限定される。

利用者向けガイドは https://bioconda.github.io、開発者向けは https://bioconda.github.io/contributor/index.html に集約されている。リポジトリの説明文は「Nightly build status」でmaster上の未アップロードレシピを夜間ジョブがビルドする旨を述べ、レシピ保守者は失敗時にPRで修正する運用が前提である。 追加段落：README一次情報に基づき、本リポジトリの公開範囲はドキュメントとソースに限定されます。star数やfork数はGitHubメタデータ由来の注目指標であり、機能保証やSLAを意味しません。導入判断では、READMEが示す具体コマンド・設定キー・バージョン番号を手元環境で再現し、期待する入出力が得られるかを記録してください。READMEに無い性能数値、互換マトリックス、セキュリティ監査結果は推測で補わず、issue/リリースノート/公式サイトで確認できる事実だけを採用記録に残します。

対応アーキテクチャと配布経路

READMEのナイトリービルド表は linux-64、osx-64、osx-arm64、linux-aarch64 の各archを列挙する。linux-64とosx-64はAzure DevOpsのNightly uploader、osx-arm64はGitHub Actions workflow nightly.yml、linux-aarch64はCircleCI（ログイン必要）で追跡される。バッジの色が赤いarchがある場合、該当レシピのビルド失敗がチャネル未反映を意味する。

パッケージ利用者は conda install -c bioconda -c conda-forge <package> が基本形である。conda-forgeを併記するのは依存解決の慣行であり、bioconda単独チャネルだけでは解決できない依存が出ることがある。導入前に conda config --show channels で優先順位を確認し、社内ミラーがある場合はチャネルURLの上書き方針を決める。 追加段落：README一次情報に基づき、本リポジトリの公開範囲はドキュメントとソースに限定されます。star数やfork数はGitHubメタデータ由来の注目指標であり、機能保証やSLAを意味しません。導入判断では、READMEが示す具体コマンド・設定キー・バージョン番号を手元環境で再現し、期待する入出力が得られるかを記録してください。READMEに無い性能数値、互換マトリックス、セキュリティ監査結果は推測で補わず、issue/リリースノート/公式サイトで確認できる事実だけを採用記録に残します。

レシピ追加とレビューの流れ

新規ツールをbiocondaに載せる場合、contributor向けドキュメントに従い recipes/<package>/meta.yaml を追加する。meta.yaml にはバージョン、ソースURL、ビルドスクリプト、テストコマンド、ライセンス SPDX が書かれる。READMEは詳細手順をサイト側に委譲しており、ローカル検証では conda-build または bioconda-utils を使う流れが一般的だが、具体コマンドはcontributor/index.html を参照する。

Matrixルーム #bioconda_Lobby:gitter.im で質問できる。open issue が1277件（素材時点）と多いのは、レシピ更新要求とビルド失敗チケットが蓄積するためである。採用判断では「人気のチャネル」という理由だけでなく、自分が依存するパッケージのレシピが最近更新されているかを個別に追う必要がある。 追加段落：README一次情報に基づき、本リポジトリの公開範囲はドキュメントとソースに限定されます。star数やfork数はGitHubメタデータ由来の注目指標であり、機能保証やSLAを意味しません。導入判断では、READMEが示す具体コマンド・設定キー・バージョン番号を手元環境で再現し、期待する入出力が得られるかを記録してください。READMEに無い性能数値、互換マトリックス、セキュリティ監査結果は推測で補わず、issue/リリースノート/公式サイトで確認できる事実だけを採用記録に残します。

ナイトリービルド失敗の読み方

README/README称、ナイトリーアップローダーはmaster上に存在するが bioconda チャネルへ未アップロードのレシピをビルドする。失敗した場合、影響レシピ向けPRが求められる。Azureの definitionId=4 ビルドページや GitHub Actions nightly.yml のログから、どのrecipe/build stringが落ちたかを特定する。

利用者視点では、conda search -c bioconda <package> でチャネル上の最新ビルドが見えるかを確認する。ナイトリーが赤でも既存ビルドが残っている場合と、新バージョンが一切来ない場合で影響が異なる。CIパイプラインでは conda list --explicit か environment.yml にピン留めした版を固定し、ナイトリー失敗ニュースと切り離して再現性を保つ。

MITライセンスと再配布

リポジトリメタデータのSPDXはMITである。レシピ自体のライセンスと、レシピがビルドする上流ソフトウェアのライセンスは別物である。meta.yaml の license フィールドと upstream の LICENSE をセットで読まないと、商用環境への再配布可否を誤判断する。

バイナリパッケージを内部ミラーに複製する場合、conda channel の terms と各パッケージのライセンス通知義務が重なる。READMEはこの点を深く述べていないため、組織ポリシーに従い法務確認が必要である。

bioconda-recipesを使う条件

再現可能なバイオinformatics環境をCondaで配りたい研究室、HPC、CI runnerにはbiocondaが定番である。Windowsのみ、あるいはDockerイメージに全依存を焼き込む方針なら、このレポジトリは直接の入口にならない。

採用前確認は三つ。conda install -c bioconda -c conda-forge で代表パッケージが解決・実行できるか、必要レシピの meta.yaml が master で最新版を追っているか、ナイトリーバッジで自分のarchが失敗していないか。レシピを自分で追加するなら contributor/index.html のチェックリストに沿ってローカルビルドログをPRに添付し、Azure/GitHub Actionsの結果をマージ条件にする。

編集部の結論

Condaでバイオinformaticsツールを再現可能に配布したい研究者やCI担当者にはbioconda-recipesが候補になる。一方、Windows専用スタックやnpm/ecosystem中心のプロジェクトにはチャネル対象外のため向かない。まず conda install -c bioconda -c conda-forge <既知パッケージ> をテスト環境で実行し、bioconda.github.io/contributor/index.html のレシピ追加手順とナイトリーバッジ（linux-64/osx-arm64）が緑かを確認してから自前レシピPRを検討する。

公式情報源

1. Official documentation
2. Official README
3. Project repository