Describe the Bug

Summary

When pyrefly writes baseline.json, files located outside the current working directory (e.g. referenced via ../../libs/foo in
search_path in pyproject.toml) are stored with absolute paths instead of relative paths in the baseline.json file. In our CI environment this leads to issues as the source location is different than it is in the local development environment. This is due to github actions checking out code to __w/<repo>/<repo> by default.

Reproduction

Given this directory structure:

  /home/user/
  ├── machine/workspace/       ← CWD, contains pyproject.toml
  │   └── src/
  │       └── ok.py         ← error here → baseline stores "src/ok.py" ✓
  └── libs/ros2/
      └── pkg/
          └── broken.py     ← error here → baseline stores "/home/user/libs/ros2/pkg/broken.py" ✗

With pyproject.toml containing:

  [tool.pyrefly]
  search_path = ["../../libs/ros2"]
  baseline = "baseline.json"

Running pyrefly check --update-baseline produces a baseline.json where:

• src/ok.py errors get a clean relative path
• ../../libs/ros2/pkg/broken.py errors get an absolute path like /home/user/libs/ros2/pkg/broken.py

The absolute path then fails to match in CI where the repo is checked out at a different location.

Expected behavior

The baseline should store ../../libs/ros2/pkg/broken.py — a relative path with .. components — so it is portable across environments.

Is fixing this of interest to the maintainers? If so, I would be willing to tackle it. 😄

Sandbox Link

Not possible due to folder structure required

(Only applicable for extension issues) IDE Information

No response