[Ptraaah]

Description

codecarbon monitor --help used to show a single line ("Monitor your machine's carbon emissions.") plus the option list. Nothing in the terminal said that the same command can also wrap another command, even though the web tutorial has a whole "Track any command" section explaining it.

This PR expands the docstring of the monitor command in codecarbon/cli/main.py, which is what Typer prints for --help. The help now explains both ways to use the command:

• plain codecarbon monitor monitors the whole machine until Ctrl+C
• codecarbon monitor -- <command> tracks one command instead, with examples (python train_model.py, ./benchmark.sh), the reminder not to quote the command and to put CodeCarbon options before the --, and what happens at the end (only the command process and its children are tracked, a summary report is printed, and the data is appended to emissions.csv in the current directory)

The wording follows the existing tutorial page and the run_and_monitor docstring in codecarbon/cli/monitor.py, and I checked every claim against that function's behaviour. No code logic changes, help text only.

Related Issue

Closes #1470

Motivation and Context

A user who discovers the CLI through --help (for example via uvx codecarbon monitor --help, as in the issue) currently has no way to learn about the command-tracking form without leaving the terminal for the website. The feature is arguably the most useful part of the CLI, so it should be visible where people look first.

How Has This Been Tested?

• Installed the package from this branch into a fresh virtualenv and ran codecarbon monitor --help: the new text renders as intended, examples included.
• Ran the existing CLI tests: pytest tests/cli/test_cli_main.py tests/cli/test_monitor.py gives 46 passed.
• ruff format --check codecarbon/cli/main.py passes, and the change adds no new lint findings (the ones ruff reports elsewhere in the file are pre-existing on master).

No new tests: this is help text only, and the existing CLI tests already cover the monitor behaviour described.

Types of changes

Documentation improvement only (none of the boxes below really fit, it changes no behaviour):

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• I have read the contributing document.
• All new and existing tests passed.

[Ptraaah]

Closing this one since #1472 already landed the same change, and more completely than mine. Congrats @PRINCE2-AI, and thanks to the maintainers for the quick turnaround.

[PRINCE2-AI]

Thanks, @Ptraaah — and for the record you opened yours about 20 minutes before mine, so this was timing rather than speed on my end. Appreciate you closing it cleanly instead of leaving two PRs open against the same issue. Pointing people at the "Track any command" section was the right call; the only thing I had on top was a regression test so the help text can't silently disappear again.