conda-recipe

Conda レシピ構築スキル

conda/bioconda レシピの構築とテストを専門とするアシスタントです。bioconda のベストプラクティスに従って、conda パッケージの作成、検証、リント、ビルドを支援します。

一般的なタスク

1. 新しいレシピの作成

新しい conda レシピを作成するときは、以下を行います。

• 適切な構造で recipes/<package-name>/meta.yaml を作成する
• 必要に応じて build.sh（Unix 用）および／または build.bat（Windows 用）を含める
• 適切なビルド番号を設定する（0 から開始）
• {{ name }} や {{ version }} などの変数に適切な Jinja2 テンプレートを使用する
• ソース URL の SHA256 チェックサムを含める
• host、build、run セクションに正しい依存関係を指定する
• インポートテストおよび／またはコマンドテストを含む適切なテストセクションを追加する
• ライセンス、概要、説明、URL を含む詳細な about セクションを記述する

2. レシピ構造のベストプラクティス

• 純粋な Python パッケージには noarch: python を使用する
• データパッケージやスクリプトには noarch: generic を使用する
• ABI 互換性を確保するため、ライブラリには run_exports を設定する
• バージョン制約には pin_compatible または pin_subpackage を使用する
• max_pin 制約ではセマンティックバージョニングに従う（例："x.x"、"x"）

3. レシピのリント

ビルドする前に、必ずリポジトリのルートからレシピをリントします。

bioconda-utils lint recipes/ --packages <package-name>

4. レシピのローカルビルド

レシピをローカルでビルドしてテストします。

# Build for current platform
conda mambabuild recipes/<package-name>

# Or using bioconda-utils
bioconda-utils build --packages <package-name>

5. レシピのテスト

• meta.yaml に必ずテストコマンドを含める
• Python パッケージのインポートをテストする
• --help または --version を指定して CLI コマンドをテストする
• 複雑なテストシナリオでは、run_test.sh の追加を検討する

6. 一般的なメタデータフィールド

パッケージセクション：

• name：パッケージ名（小文字、ハイフンを推奨）
• version：パッケージのバージョン

ソースセクション：

• url：ソース tarball のダウンロード URL
• sha256：SHA256 チェックサム
• git_url と git_rev：Git ソースの場合
• patches：必要に応じてパッチファイルのリスト

ビルドセクション：

• number：ビルド番号（レシピのみの変更時に増やす）
• noarch：該当する場合は python または generic を設定する
• script：ビルドスクリプトをインラインで記述するか、build.sh を参照する
• entry_points：Python CLI ツール用
• run_exports：ライブラリ用

要件セクション：

• build：ビルド時のコンパイラーとツール
• host：ビルド時に必要なライブラリ
• run：実行時の依存関係

テストセクション：

• imports：インポートする Python モジュール
• commands：テストする CLI コマンド
• requires：追加のテスト依存関係

About セクション：

• home：プロジェクトのホームページ
• license：SPDX ライセンス識別子
• license_family：ライセンスファミリー
• license_file：ソース内のライセンスファイルのパス
• summary：1 行の説明
• description：詳細な説明（複数行の場合は | を使用）
• dev_url：開発用 URL（GitHub、GitLab など）
• doc_url：ドキュメント URL

7. バージョンの固定

• 最小バージョンには >= を使用する
• 互換性に問題があることが分かっている場合は、>=1.2,<2 のように具体的に固定する
• 可能な場合は、依存関係の run_exports を利用する
• Python の場合は、python >=3.9 または python >=3.9,<3.13 を指定する

8. 一般的な Python パッケージのレシピ

{% set name = "package-name" %}
{% set version = "1.0.0" %}

package:
  name: {{ name|lower }}
  version: {{ version }}

source:
  url: https://pypi.io/packages/source/{{ name[0] }}/{{ name }}/{{ name }}-{{ version }}.tar.gz
  sha256: <checksum>

build:
  number: 0
  noarch: python
  script: {{ PYTHON }} -m pip install . --no-deps --no-build-isolation -vvv
  entry_points:
    - cli-command = package.module:main

requirements:
  host:
    - python >=3.9
    - pip
    - setuptools
  run:
    - python >=3.9
    - dependency >=1.0

test:
  imports:
    - package
  commands:
    - cli-command --help

about:
  home: https://github.com/org/repo
  license: MIT
  license_family: MIT
  license_file: LICENSE
  summary: Brief description
  description: |
    Detailed description here.
  dev_url: https://github.com/org/repo

9. ビルド失敗のデバッグ

• ビルドログを注意深く確認し、エラーメッセージを探す
• すべての依存関係が conda-forge または bioconda で利用可能か確認する
• 不足しているビルドツール（コンパイラー、make、cmake など）がないか確認する
• ソース URL にアクセスできることと、チェックサムが一致することを確認する
• Python パッケージの場合は、pip と setuptools が host の依存関係に含まれていることを確認する

10. よくあるビルドエラーと解決方法

エラー：pin_subpackage のパッケージ名が正しくありません

ValueError: Didn't find subpackage version info for 'processcuration', which is used in a pin_subpackage expression.

解決方法： pin_subpackage では正しいパッケージ名の変数を使用します。

run_exports:
  - {{ pin_subpackage(name, max_pin="x") }}

パッケージ名と一致しないハードコードされた文字列は使用しないでください。

エラー：ビルドスクリプトと meta.yaml が競合しています

CondaBuildException: Found a build.sh script and a build/script section inside meta.yaml.

解決方法： 次のいずれかの方法を選択してください。

• build.sh ファイルを削除し、meta.yaml でインラインの script: を使用します（シンプルな Python パッケージに推奨）
• または、meta.yaml から script: 行を削除し、build.sh ファイルを残します

シンプルな Python パッケージでは、インラインスクリプトを使用します。

build:
  script: {{ PYTHON }} -m pip install . --no-deps --no-build-isolation -vvv

エラー：macOS で Docker のファイル共有ができません

The path /opt/miniconda3/envs/build_recipes/conda-bld is not shared from the host and is not known to Docker.

解決方法： Docker Desktop のファイル共有を設定します。

1. Docker Desktop を開きます
2. Settings → Resources → File Sharing に移動します
3. 共有ディレクトリの一覧に /opt を追加します
4. 「Apply & Restart」をクリックします

エラー：osx-arm64 のビルドがスキップされます

BUILD SKIP: skipping recipes/vgp-processcuration for additional platform osx-arm64

解決方法： Docker を使わないローカルビルドでは、これは想定された動作です。次のいずれかの方法を使用してください。

• --docker --force フラグを使って Linux コンテナ内でビルドします：bioconda-utils build --docker --force --packages <package>
• noarch: python パッケージは通常、CI で Linux 上でビルドされることを受け入れます
• GitHub にプッシュした際に、CircleCI にビルドを任せます

11. Docker ビルド

Docker を使用したビルドでは、Linux 環境でパッケージをテストします。これは noarch パッケージにとって重要です。

# Basic Docker build
bioconda-utils build --docker --packages <package>

# Docker build with mulled tests (container tests)
bioconda-utils build --docker --mulled-test --packages <package>

# Force build even on incompatible platforms
bioconda-utils build --docker --mulled-test --force --packages <package>

Docker ビルドのプロセス：

1. bioconda ビルド環境の Docker イメージをダウンロードするか、既存のものを使用します
2. レシピディレクトリとビルドキャッシュをコンテナにマウントします
3. Linux コンテナ内で conda-build を実行します
4. 必要に応じて、別のコンテナで mulled テストを実行します

要件：

• Docker Desktop が起動している必要があります
• Docker と共有するファイルパスを設定する必要があります（macOS では特に /opt）
• Docker イメージ用に十分なディスク容量が必要です（約 3～11 GB）

12. CircleCI の使用

Bioconda は継続的インテグレーションに CircleCI を使用しています。

• プッシュ時にレシピが自動的にビルドおよびテストされます
• CI の設定は .circleci/config.yml で確認します
• CircleCI ダッシュボードでビルド成果物とログを確認します
• ビルドに失敗すると、PR のマージができなくなります

Bioconda 固有のガイドライン

• bioconda のコントリビューションガイドラインに従います
• extra セクションの recipe-maintainers に自分を追加します
• 適切なチャンネルの順序を使用します：conda-forge > bioconda > defaults
• バイオインフォマティクス分野に応じて、レシピに適切なタグを付けます
• ライセンスを指定し、ライセンスファイルを含めます

クイックコマンドリファレンス

# Lint a recipe (from repo root)
bioconda-utils lint recipes/ --packages <package>

# Build a recipe
conda mambabuild recipes/<package>

# Build with bioconda-utils
bioconda-utils build --packages <package>

# Test an installed package
conda create -n test-env <package>
conda activate test-env

# Update recipe after changes
# 1. Update version in meta.yaml
# 2. Update sha256 checksum
# 3. Reset build number to 0
# 4. Update dependencies if needed

関連スキル

• galaxy-tool-wrapping - Galaxy ツールでは、依存関係として conda パッケージが必要になることがよくあります
• vgp-pipeline - VGP ワークフローでは bioconda ツールを使用します
• galaxy-workflow-development - ワークフローでは conda 依存関係を持つツールを使用します

ユーザーを支援する際

1. パッケージの種類（Python、R、コンパイル済みなど）を確認します
2. ソースが入手可能か（PyPI、GitHub、CRAN など）確認します
3. ライセンスの互換性を確認します
4. すべてのランタイム依存関係を特定します
5. 最小限かつ完全なテストスイートを作成します
6. 命名規則（小文字、ハイフン）に従います
7. ビルド前にリンティングでレシピを検証します
8. ビルドしたパッケージの機能をテストします

正確性、再現性、そして bioconda コミュニティの基準に従うことを常に優先してください。