conda-forge-author

name

conda-forge-author

description

Author and maintain conda-forge packages: staged-recipes PRs, feedstock recipe edits, grayskull/rattler-build v1 recipes, linter fixes, and review responses. CRITICAL guardrails against replacing the official staged-recipes PR checklist with custom bodies. Use when working on staged-recipes, feedstocks, recipe.yaml, meta.yaml, grayskull, conda-forge-admin linter, @conda-forge/help-*, ocefpaf review comments, or "add recipe" / "conda-forge PR" / "restore checklist". Complements cf-ci (CI logs) and conda-forge-reviewer (reviewing others).

conda-forge-author

Authoring path for your staged-recipes and feedstock PRs. Reviewing others → conda-forge-reviewer. CI logs → cf-ci.

CRITICAL :: staged-recipes PR body (never "AI slop")

Reviewers (incl. core) reject custom PR bodies. Real feedback received:

Can you please restore our checklist instead of overriding it with what it looks like some AI slop?

Hard rules

1. Never replace the official PR template / checklist with a custom markdown body.
2. Forbidden body shapes (any of these = stop and restore official template):
   • Short fake checklists (- [x] Meaningful title, - [x] License packaged, …)
   • ## Package / ## Notes / ## Checklist sections you invented
   • Recipes: \foo`+Maintainer: @…` blurb as the whole body
   • Marketing prose, emoji banners, "ready for review" in the body (that goes in a comment, once)
3. Allowed body = official template only:
   • Keep the full HTML comment block from https://raw.githubusercontent.com/conda-forge/staged-recipes/main/.github/pull_request_template.md
   • Keep the literal Checklist heading and all ten official items, verbatim wording
   • Fill items with [x] / [ ] from the recipe, not vibes
   • Optional: one short plain sentence above the HTML comment (package name + what it is). No bullet lists. No second checklist.
4. Before every gh pr create / gh pr edit --body:
   • Fetch the live template (do not trust memory)
   • Assert body contains the exact substring: License file is packaged (see [here]
   • Assert body does not contain custom markers: ## Package, ## Notes, Recipes:, Maintainer:
5. Copy of official checklist text: references/staged-recipes-pr-body.md in this skill (refresh from upstream if it drifts).

Filling the ten boxes

Item	When [x]
Meaningful title	Title like Add recipe <name>
License file packaged	about.license_file present; rust: THIRDPARTY.yml via cargo-bundle-licenses when needed
Official source	PyPI / GitHub release or archive url, not a random mirror
No vendoring	No bundled third-party trees; or licenses shipped for all
Static lib license	N/A pure python → [x]; else licenses for static deps present
No static libs shipped	Shared-only / pure python / CFEP-18 if static needed
Build number 0	build.number: 0 on new recipes
Tarball url	source.url + sha256; never git_url for the default path
Maintainers confirmed	Listed maintainers are willing (author self-OK; co-maintainers need their comment)
Knowledge base	Always [x] once you used docs instead of blind pings

Public surface etiquette

• Do not comment on staged-recipes PRs unless the user explicitly asks for a comment, or a single required ping (@conda-forge/help-python, ready for review!) after CI is green.
• Do not post "Restored checklist", "Thanks, updated", status spam, or multi-PR bulk comments.
• Body edits to restore the official checklist are fine when the user asked to fix review feedback; still no chaser comment unless asked.
• gitguard blocks gh pr edit|comment|create by default. Only use GITGUARD_BYPASS_GH=1 when the user explicitly ordered that public action this turn.
• Never attribute AI. Never put agent/process narration in PR text.

Recipe authoring (v1 preferred)

Prefer rattler-build v1 recipe.yaml under recipes/<name>/. Upstream examples:

• v1: recipes/example-v1/recipe.yaml on staged-recipes
• v0: recipes/example/meta.yaml (legacy)

Generate drafts with grayskull when possible, then hand-fix to match current CF norms.

Source URLs (bot auto-updates)

Use patterns the bot can follow — not frozen files.pythonhosted.org/.../hash/... paths.

# PyPI (preferred form)
source:
  url: https://pypi.org/packages/source/${{ name[0] }}/${{ name }}/${{ name }}-${{ version }}.tar.gz
  # or explicit first letter path as in example-v1:
  # url: https://pypi.org/packages/source/s/simplejson/simplejson-${{ version }}.tar.gz
  sha256: <digest>

# GitHub tag archive
source:
  url: https://github.com/org/repo/archive/refs/tags/v${{ version }}.tar.gz
  sha256: <digest>

Reviewers flag hardcoded wheelhouse hash URLs: fix to pypi.org/packages/source/.../${{ version }}.tar.gz.

noarch Python pins (linter)

build:
  noarch: python
  number: 0
  script: ${{ PYTHON }} -m pip install . -vv --no-deps --no-build-isolation

requirements:
  host:
    - python ${{ python_min }}.*
    - pip
    - <build backend>
  run:
    - python >=${{ python_min }}
    - <deps>

tests:
  - python:
      imports:
        - <module>
      python_version:
        - ${{ python_min }}.*
        - "*"          # reviewers often want min + latest
      pip_check: true

• Do not set context.python_min unless the package needs a higher floor than the conda-forge default.
• Compiled Python extensions: not noarch; pin python in host/run per matrix norms.

Other recipe norms

• build.number: 0 for new packages; bump only on rebuilds.
• SPDX about.license; always license_file.
• extra.recipe-maintainers with GitHub usernames (you: HaoZeke).
• Skip windows only with a real reason in a short recipe comment, not a PR essay.

CRITICAL :: one package, no duplicate recipes

Real feedback:

This one is already merged from another PR. See https://github.com/conda-forge/rgpycrumbs-feedstock/...

What happened: standalone rgpycrumbs PR (#34080) was open while pychum PR (#34088) also shipped recipes/rgpycrumbs/. #34088 merged first → feedstock created → #34080 closed as duplicate. Waste of reviewer time.

Hard rules

1. Default: one new package name per staged-recipes PR. Directory = recipes/<name>/ only.
2. Never add recipes/<dep>/ into package B's PR if <dep> already has:
   • an open staged-recipes PR, or
   • a conda-forge/<dep>-feedstock, or
   • a merged staged-recipes PR that created the feedstock.
3. If B depends on A and A is not on conda-forge yet:
   • Open A first (its own PR), wait for merge/feedstock, then open B with run dep on A; or
   • One PR with only tightly-coupled co-recipes that will never have separate PRs (e.g. asv_env_rattler + asv_env_pixi as a single unit you own end-to-end). Document the pairing in the title: Add recipes asv_env_rattler and asv_env_pixi.
4. Before opening (or pushing more packages into) a PR, for every recipes/<name>/ in the diff:

# feedstock already live?
gh api "repos/conda-forge/${name}-feedstock" --jq .full_name
# any open staged-recipes PR already adding this recipe?
gh pr list --repo conda-forge/staged-recipes --state open --search "recipes/${name}" --json number,title,url
# your own open PRs (catch self-duplicates)
gh pr list --repo conda-forge/staged-recipes --author @me --state open --json number,title,files

If feedstock exists or another open PR already has recipes/<name>/ → do not open/keep a second recipe; close the duplicate without a chaser essay (user may close silently). 5. After any of your staged-recipes PRs merges, immediately re-scan remaining open PRs for package-name overlap and close duplicates.

Review table add-on

Feedback	Action
Already merged / feedstock exists	Close the duplicate PR (no debate). Prefer silent close or one-line if user asked.

Review response workflow

When a staged-recipes reviewer comments:

1. Read the full thread + linked review (e.g. "same comments as #N").
2. Fix recipes in the PR branch first (source URL, python_min, tests).
3. PR body: if checklist was replaced or mangled → restore official template + fill. Nothing else in the body.
4. Push to the PR head branch (fork remote; not force-push upstream).
5. Comments: only if the user asked, or a single maintainer-confirm / team-ping is required. Prefer silence after a push that addresses the review.
6. CI: use cf-ci status|errors|watch on the PR URL; do not WebFetch Azure pages.

Common ocefpaf / help-python points (fix, don't argue in public):

Feedback	Action
Source URL not bot-friendly	Switch to pypi.org/packages/source/.../${{ version }}.tar.gz
Drop needless python_min in context	Remove override; use global CF min
Test both min and latest python	python_version: [ ${{ python_min }}.*, "*" ]
Restore checklist	Official template only; fill [x]
Already merged / feedstock exists	Close duplicate; do not re-add the recipe
License / static / tarball	Fix recipe; re-check the ten boxes

Feedstock maintenance (post-merge)

• Version bumps: usually the bot; manual → edit recipe.yaml / meta.yaml, bump build.number only when source unchanged.
• Rerender: @conda-forge-admin, please rerender (user must authorize the comment).
• CI failures: cf-ci errors <feedstock> --pr=N then fix recipe; never skip tests to green CI.

Tooling map

Need	Tool
CI status / logs / errors	cf-ci skill + CLI
Review others' staged-recipes	conda-forge-reviewer
Draft recipe	grayskull / hand-written v1
PR draft offline	issue-pr vault drafts; paste only when user files
Public GH write	GITGUARD_BYPASS_GH=1 only on explicit user order

Pre-flight (before open or re-open claim)

• No duplicate: no conda-forge/<name>-feedstock; no other open PR with recipes/<name>/
• One package per PR (or an intentional co-recipe set with no parallel PRs for those names)
• Recipe is v1 (or justified v0)
• Source URL bot-friendly + sha256
• noarch python pins correct; no spurious python_min override
• Tests import (+ pip_check unless known false upstream metadata)
• PR body is official template + filled checklist only
• Title: Add recipe <name> (or Add recipes a and b for intentional co-recipes)
• No unsolicited PR comments
• Linter green (conda-forge-admin "excellent condition" or checks SUCCESS)

Anti-patterns (do not)

• Rewrite PR body into a "nice" summary for the reviewer
• Bulk-comment the same sentence across many PRs
• Claim bot lint is open when a later "excellent condition" already landed
• Invent a second checklist "aligned with" the official one
• Put @conda-forge/help-* in the PR body instead of a comment
• Ship dependency recipes/<dep>/ inside another package's PR while <dep> also has its own PR
• Leave a standalone PR open after a co-recipe PR that includes the same package merges