This repo is for making requests to conda-forge/core for various administrative
tasks.
If you want to mark a package as broken on conda-forge, send a Pull Request
adding a new .yml file in requests folder with a list of the full names of the packages
for which the broken label will be added. See examples/example-broken.yml for an example.
Guidelines for marking packages as broken:
- If the package is functional but with incorrect metadata (e.g. missing dependencies), then 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.
If you want to remove the broken label from packages on conda-forge, send a Pull Request
adding a new .yml file in requests folder with a list of the full names of the packages
for which the label broken will be removed. See examples/example-not-broken.yml for an example.
If you want to reset your feedstock token to fix issues with uploads, send a Pull Request
adding a new .yml file in requests folder with a list of the feedstock names
without -feedstock. See examples/example-token-reset.yml for an example.
(e.g., for python-feedstock, the feedstocks list must contain python).
If you want to request a feedstock to be archived, send a Pull Request
adding a new .yml file in requests folder with a list of the feedstock names
without -feedstock. See examples/example-archive.yml for an example.
(e.g., for python-feedstock, the feedstocks list must contain python).
For unarchiving, see examples/example-unarchive.yml for an example.
For feedstocks that need to be archived, please leave an open issue with some details about why that decision was taken (e.g. it has been deprecated by a new feedstock), and link it in your PR description.
Certain CI resources are opt-in only. If you want to request access to these resources, please
submit a PR adding your feedstock name to a new .yml file in requests folder.
Available opt-in resources:
- Travis CI: See
examples/example-travis.yml open-gpu-server(includes GPU CI and long-running builds): Seeexamples/example-open-gpu-server.yml.
CFEP-3 specifies the process to add foreign builds to conda-forge. Read the CFEP for more details. This workflow allows users to request a copy once the manual review has been passed.
To do so, please create a new .yml file in the requests folder. Check examples/example-cfep-3.yml for the required metadata.
For provenance and transparency, the PR description must include a link to the original PR and the logs, along with the artifact(s) to be reviewed.
By default, conda-forge feedstocks cannot push packages to our channel that another feedstock makes. If you encountered an error
when building your package indicating that the given package was not allowed for your feedstock (e.g., you moved a package
build from one feedstock to another), you should request the output be added to the new feedstock via this repository. An example request
is located in examples/example-add-feedstock-output.yml. You can add both glob patterns
and package names. We support the glob syntax of the Python fnmatch module. Make a PR putting your
.yml request file in the requests directory and the conda-forge/core team will review it.