diff --git a/docs/how-to/contributing.md b/docs/how-to/contributing.md
index 243bb80d2..a5851fc6c 100644
--- a/docs/how-to/contributing.md
+++ b/docs/how-to/contributing.md
@@ -22,6 +22,9 @@
- [Build Documentation 🖨️](#build-documentation)
- [Release process](#release-process)
- [Test the build in Docker](#test-the-build-in-docker)
+ - [Conda-forge packaging](#conda-forge-packaging)
+ - [How a release reaches conda-forge](#how-a-release-reaches-conda-forge)
+ - [Updating the recipe by hand](#updating-the-recipe-by-hand)
- [API and Dashboard](#api-and-dashboard)
- [CSV Dashboard](#csv-dashboard)
- [Web dashboard](#web-dashboard)
@@ -323,6 +326,7 @@ git push --force-with-lease
- Wait for the Github Action `ReleaseDrafter` to finish running on the merge commit.
- [Edit the Draft release](https://github.com/mlco2/codecarbon/releases/) on Github and give it a tag, `v1.0.0` for the version 1.0.0. Github will automatically create a Git tag for it. Complete help [here](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository).
- A [Github Action](https://github.com/mlco2/codecarbon/actions) _Upload Python Package_ will be run automaticaly to upload the package.
+- Nothing to do for conda: the [conda-forge](#conda-forge-packaging) package is built from PyPI a few hours later.
#### Test the release
@@ -359,6 +363,75 @@ cp /data/tests/test_package_integrity.py .
pytest test_package_integrity.py
```
+
+### Conda-forge packaging
+
+CodeCarbon is distributed on [conda-forge](https://anaconda.org/conda-forge/codecarbon)
+in addition to PyPI, so that conda users can install it with:
+
+```bash
+conda install -c conda-forge codecarbon
+```
+
+Nothing in this repository builds that package. Conda-forge builds every package from
+a dedicated repository called a *feedstock*, ours being
+[conda-forge/codecarbon-feedstock](https://github.com/conda-forge/codecarbon-feedstock).
+The build instructions live there in `recipe/meta.yaml`, and the people allowed to
+approve changes are listed at the bottom of that file under `extra: recipe-maintainers`.
+
+
+#### How a release reaches conda-forge
+
+1. We publish to PyPI, as described in [Release process](#release-process).
+2. A few hours later `regro-cf-autotick-bot` notices the new version, and opens a PR on
+ the feedstock bumping the version and the source `sha256`. It also re-reads the
+ dependencies from the published package and updates the recipe accordingly.
+3. Conda-forge CI builds the package and runs the tests declared in the recipe, which
+ for us are `pip check` plus `codecarbon --help`.
+4. `conda-forge.yml` sets `bot: automerge: true`, so the PR merges itself once CI is
+ green and the package is uploaded to the `conda-forge` channel.
+
+A normal release therefore needs **no action** from us. `pip check` is the safety net:
+if a dependency is missing or is named differently on conda-forge, CI fails, the PR
+stays open, and a maintainer has to step in.
+
+
+#### Updating the recipe by hand
+
+Needed when the bot PR fails, or when the recipe has drifted from `pyproject.toml`
+(a new dependency, a dropped Python version, a renamed entry point).
+
+Two conda-forge rules make this different from a normal PR:
+
+- **Always work from a personal fork.** Conda-forge refuses PRs opened from a branch of
+ the feedstock itself, and its bot cannot push to a fork owned by an organisation. Fork
+ to your own account, not to `mlco2`.
+- **Never edit the generated files by hand.** `README.md`, `.ci_support/`, and the CI
+ workflows are produced by `conda-smithy`. To refresh them, comment on the PR:
+
+ ```text
+ @conda-forge-admin, please rerender
+ ```
+
+ The bot pushes the regenerated files to your branch. A feedstock that has not been
+ rerendered for a long time will fail to build at all, because its pinned CI container
+ eventually becomes too old for conda-forge tooling.
+
+To update the recipe itself:
+
+- Set `version`, and take the matching `sha256` from the sdist on
+ [PyPI](https://pypi.org/project/codecarbon/#files).
+- Mirror the `dependencies` of our `pyproject.toml` into `requirements: run`. Conda
+ package names occasionally differ from PyPI ones, and environment markers such as
+ `python_version >= "3.14"` cannot be expressed in a `noarch: python` recipe.
+- Do not hardcode a Python version: use `{{ python_min }}`, which comes from
+ conda-forge's global pinning.
+- The optional `carbonboard` extra is shipped as a separate `codecarbon-viz`
+ metapackage, so its dependencies must be updated there too.
+
+Adding someone to `extra: recipe-maintainers` requires that person to comment on the PR
+to confirm.
+
### Contribute to a fork branch
When a user open a PR from a fork, we are allowed to push to the fork branch.
diff --git a/docs/how-to/installation.md b/docs/how-to/installation.md
index a1113c222..0c53f5c90 100644
--- a/docs/how-to/installation.md
+++ b/docs/how-to/installation.md
@@ -1,5 +1,9 @@
# Installing CodeCarbon {#installation}
+!!! note "Python Support"
+
+ We recommend using a [supported Python version](https://devguide.python.org/versions/).
+
## From PyPi repository
The package is hosted on the pip repository
@@ -22,13 +26,18 @@ conda activate codecarbon
pip install codecarbon
```
-!!! warning "Conda Support"
+!!! note "Conda Support"
+
+ Starting from 3.3.0 we start to maintain again an official Conda packages on [conda-forge](https://anaconda.org/channels/conda-forge/packages/codecarbon/overview):
+
+
+ ``` bash
+ conda install -c conda-forge codecarbon
+ ```
- While CodeCarbon can be used in Conda environments, we no longer maintain official Conda packages. We recommend using `pip install codecarbon` within your Conda environment, which works seamlessly. The conda package may be outdated and is not officially supported.
+ The [channel `codecarbon`](https://anaconda.org/channels/codecarbon/packages/codecarbon/overview) is outdated.
-!!! note "Note"
- We recommend using Python 3.8 or above.
## Dependencies