Relative paths resolved without changing the working directory

[mauvilsa]

What does this PR do?

Relative paths in a config file are resolved with respect to the directory of that file. This was done by temporarily changing the process working directory with os.chdir, which is process-global state, with several consequences, most visible for configs in temporary directories:

• Removing the original working directory while a config was loading made restoring it raise FileNotFoundError.
• os.getcwd() resolves symlinks, so a config under a symlinked directory gave back paths the user never wrote.
• Parsing configs concurrently in threads resolved paths against each other's directories or failed outright.

Changes:

• _paths.py: change_to_path_dir is renamed to path_dir_context, since it no longer changes any directory. It sets the new current_local_dir context variable, which Path.__init__ uses for local relative paths. Keeping it separate from _current_path_dir means a local path inside a remote config still resolves against the closest local directory.
• _formatters.py: get_initial_working_directory is removed, the working directory is now always the initial one. _describe_origin falls back to the absolute path when the working directory is gone, so that a removed directory does not mask the parse error being reported.
• _loaders_dumpers.py: jsonnet resolves import statements relative to the file name given to evaluate_snippet, previously found through the working directory, now anchored on current_local_dir. Its base name is used, which also fixes from_config for a config given as a relative path with a directory, e.g. sub/config.jsonnet, broken the same way before this change.
• typing.py: a path dumped with path_dump_preserve_relative is reloaded by passing its stored cwd to the Path constructor, instead of the context manager, which required that directory to exist.

Code that relied on the working directory, e.g. a custom type that opens a relative path, must now use a path type such as Path_fr. A class_path naming a module next to the config file also stops working, since that resolved through the working directory; it was never a documented feature, so it can be added back on request. The migration guide lists this as breaking.

Not addressed: a working directory removed before parsing starts still raises FileNotFoundError, even for an absolute config path.

Before submitting

• Did you read the contributing guideline?
• If you used a coding agent, did you fully understand and validate all generated code and ensure it follows the contributing guidelines?
• Did you update the documentation? (readme and public docstrings)
• Did you write unit tests such that there is 100% coverage on related code? (required for bug fixes and new features)
• Did you verify that new and existing tests pass locally?
• If this is a bug fix, did you verify that the tests fail without the code fix?
• Did you make sure that all changes preserve backward compatibility?
• Did you update the CHANGELOG including a pull request link? (not for typos, docs, test updates, or minor internal changes/refactors)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (b8c053c) to head (d9594b4).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff            @@
##              main      #979   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           27        27           
  Lines         9079      9077    -2     
=========================================
- Hits          9079      9077    -2     

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

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud