Mark all build packages as broken; use python-build instead

[zklaus]

Guidelines for marking packages as broken:

• We prefer to patch the repo data (see here) instead of marking packages as broken. This alternative workflow makes environments more reproducible.
• Packages with requirements/metadata that are too strict but otherwise work are not technically broken and should not be marked as such.
• Packages with missing metadata can be marked as broken on a temporary basis but should be patched in the repo data and be marked unbroken later.
• In some cases where the number of users of a package is small or it is used by the maintainers only, we can allow packages to be marked broken more liberally.
• We (conda-forge/core) try to make a decision on these requests within 24 hours.

What will happen when a package is marked broken?

• Our bots will add the broken label to the package. The main label will remain on the package and this is normal.
• Our bots will rebuild our repodata patches to remove this package from the repodata.
• In a few hours after the anaconda.org CDN picks up the new patches, you will no longer be able to install the package from the main channel.

Checklist:

• [x] I want to mark a package as broken (or not broken):
  • [x] Added a description of the problem with the package in the PR description.
  • [x] Pinged the team for the package for their input.

There is a bit of a lingering issue with the build packages. This was discussed in the conda-forge core meeting on 2024-08-21. Here is an excerpt from the notes. Marking the build packages as broken and directing users to the python-build packages is the agreed-upon strategy.

• [x] (KZ) python-build vs build issue
  • Brief summary:
    • The builder https://build.pypa.io was first added in the python-build-feedstock in 2020 and then again by error in the build-feedstock in 2021, which was subsequently archived.
    • Now there are both python-build and build packages, but the build packages are horribly outdated
    • People and packagers use build, find it outdated and run around confused until they come upon python-build.
    • We have a migrator hanging around on the status page with all entries 0.
  • Ways forward:
    • Add an alias build to python-build so both names work with current versions?
    • Mark all build packages broken to force people to migrate?
    • Close out migrator/finish it if needed?
  • MRB: where has this happened recently?
    • KZ: I am not aware of any actual, recent issues. I just stumbled into this again because I was looking to make some headway with migrators in general and this one, with 0 everywhere, stuck out and reminded me of the discussion.
  • MRB: we should add an entry to this file: https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/linter_hints/hints.toml to make the linter warn about using build. See PR https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/6313
  • MRB: FWIW, the migrator will repopulate itself if any new feedstocks add a reference to build and then the bot will send a PR.
  • to do items:
    • merge linter hints
    • mark existing build packages as broken (KZ: https://github.com/conda-forge/admin-requests/pull/1048)
    • make announcement saying we won't ever bring build back

ping @conda-forge/build, @conda-forge/python-build, @conda-forge/core.

[zklaus]

I was too slow, #1049 took care of this.