fix: resolve RAM default pid at init time

[davidberenstein1957]

Description

RAM.__init__ took pid: int = psutil.Process().pid as a default argument. Python evaluates default arguments once at import time, so the value was frozen to whichever process first imported codecarbon.external.ram and that stale value survived fork(). The default is now None, resolved to os.getpid() inside __init__, matching how CPU already does it in external/hardware.py.

Related Issue

Fixes #1318

Motivation and Context

Neither construction site passes a pid (core/resource_tracker.py:37, core/hardware_cache.py:164), so the stale default was always in use. In a forked child with tracking_mode="process" this meant measuring the parent's RSS plus every sibling worker, or, if the parent had exited, a NoSuchProcess error that total_power swallows into a silent 0 W for the rest of the run.

How Has This Been Tested?

New test tests/test_ram.py::TestRAM::test_default_pid_is_resolved_at_init mocks os.getpid and asserts RAM(tracking_mode="process")._pid matches the mocked value, i.e. that the pid is resolved at construction time rather than frozen at import time. uv run pytest tests/test_ram.py is green (21 passed).

Screenshots (if appropriate):

N/A

Types of changes

• 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)

AI Usage Disclosure

• 🟥 AI-vibecoded: You cannot explain the logic. Car analogy : the car drive by itself, you are outside it and just tell it where to go.
• 🟠 AI-generated: Car analogy : the car drive by itself, you are inside and give instructions.
• ⭐ AI-assisted. Car analogy : you drive the car, AI help you find your way.
• ♻️ No AI used. Car analogy : you drive the car.

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the docs/how-to/contributing.md document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.04%. Comparing base (7a47f7a) to head (7cdf451).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1326   +/-   ##
=======================================
  Coverage   92.04%   92.04%           
=======================================
  Files          49       49           
  Lines        5153     5154    +1     
=======================================
+ Hits         4743     4744    +1     
  Misses        410      410           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[benoit-cty]

🤖 This review comment was written and posted by Claude Opus 5.5 (AI assistant), at the request of @benoit-cty. Findings were checked by reading the code and running tests locally (merged with current master where relevant), but please double-check before acting on them.

Verdict: ✅ Approve with nits

The bug is real. pid: int = psutil.Process().pid runs once, when the module is imported. So a forked child in process mode measures its parent, and reports 0 W silently on NoSuchProcess. Resolving os.getpid() in __init__ when pid is None is correct. The hardware cache rebuilds RAM from specs, so it can't hold on to a stale instance. 21 tests pass.

Nits:

1. The test forks inside multi-threaded pytest, which gives a DeprecationWarning on Python 3.12+ and can be flaky. Patching os.getpid (e.g. mock.patch("os.getpid", return_value=12345)) and asserting RAM()._pid == 12345 would be simpler and deterministic.
2. If RAM() raises in the child, the parent currently fails with a confusing int(''). If you keep the fork, write an explicit sentinel or the exit status instead.
3. The branch is behind master; please update it before merge.

[davidberenstein1957]

Made the changes in bb22b62: swapped the fork test for a deterministic os.getpid mock (which also removes the int('') issue), and merged master in.

[benoit-cty]

Great!