2026-01-20 10:55:01 -08:00
|
|
|
use dirs::home_dir;
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
use path_absolutize::Absolutize;
|
2025-12-12 15:25:22 -08:00
|
|
|
use schemars::JsonSchema;
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
use serde::Deserialize;
|
|
|
|
|
use serde::Deserializer;
|
|
|
|
|
use serde::Serialize;
|
|
|
|
|
use serde::de::Error as SerdeError;
|
|
|
|
|
use std::cell::RefCell;
|
|
|
|
|
use std::path::Display;
|
|
|
|
|
use std::path::Path;
|
|
|
|
|
use std::path::PathBuf;
|
2025-12-12 15:25:22 -08:00
|
|
|
use ts_rs::TS;
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
|
|
|
|
|
/// A path that is guaranteed to be absolute and normalized (though it is not
|
|
|
|
|
/// guaranteed to be canonicalized or exist on the filesystem).
|
|
|
|
|
///
|
|
|
|
|
/// IMPORTANT: When deserializing an `AbsolutePathBuf`, a base path must be set
|
2025-12-22 11:07:36 -08:00
|
|
|
/// using [AbsolutePathBufGuard::new]. If no base path is set, the
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
/// deserialization will fail unless the path being deserialized is already
|
|
|
|
|
/// absolute.
|
2026-01-07 12:11:12 -08:00
|
|
|
#[derive(Debug, Clone, PartialEq, Eq, Hash, Serialize, JsonSchema, TS)]
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
pub struct AbsolutePathBuf(PathBuf);
|
|
|
|
|
|
|
|
|
|
impl AbsolutePathBuf {
|
2026-01-20 10:55:01 -08:00
|
|
|
fn maybe_expand_home_directory(path: &Path) -> PathBuf {
|
|
|
|
|
let Some(path_str) = path.to_str() else {
|
|
|
|
|
return path.to_path_buf();
|
|
|
|
|
};
|
|
|
|
|
if cfg!(not(target_os = "windows"))
|
|
|
|
|
&& let Some(home) = home_dir()
|
|
|
|
|
{
|
|
|
|
|
if path_str == "~" {
|
|
|
|
|
return home;
|
|
|
|
|
}
|
|
|
|
|
if let Some(rest) = path_str.strip_prefix("~/") {
|
2026-01-21 10:43:10 -08:00
|
|
|
let rest = rest.trim_start_matches('/');
|
|
|
|
|
if rest.is_empty() {
|
|
|
|
|
return home;
|
|
|
|
|
}
|
2026-01-20 10:55:01 -08:00
|
|
|
return home.join(rest);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
path.to_path_buf()
|
|
|
|
|
}
|
|
|
|
|
|
2025-12-12 15:25:22 -08:00
|
|
|
pub fn resolve_path_against_base<P: AsRef<Path>, B: AsRef<Path>>(
|
|
|
|
|
path: P,
|
|
|
|
|
base_path: B,
|
|
|
|
|
) -> std::io::Result<Self> {
|
2026-01-20 10:55:01 -08:00
|
|
|
let expanded = Self::maybe_expand_home_directory(path.as_ref());
|
|
|
|
|
let absolute_path = expanded.absolutize_from(base_path.as_ref())?;
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
Ok(Self(absolute_path.into_owned()))
|
|
|
|
|
}
|
|
|
|
|
|
2025-12-12 15:25:22 -08:00
|
|
|
pub fn from_absolute_path<P: AsRef<Path>>(path: P) -> std::io::Result<Self> {
|
2026-01-20 10:55:01 -08:00
|
|
|
let expanded = Self::maybe_expand_home_directory(path.as_ref());
|
|
|
|
|
let absolute_path = expanded.absolutize()?;
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
Ok(Self(absolute_path.into_owned()))
|
|
|
|
|
}
|
|
|
|
|
|
2025-12-19 20:11:27 -08:00
|
|
|
pub fn current_dir() -> std::io::Result<Self> {
|
|
|
|
|
let current_dir = std::env::current_dir()?;
|
|
|
|
|
Self::from_absolute_path(current_dir)
|
|
|
|
|
}
|
|
|
|
|
|
2025-12-12 15:25:22 -08:00
|
|
|
pub fn join<P: AsRef<Path>>(&self, path: P) -> std::io::Result<Self> {
|
|
|
|
|
Self::resolve_path_against_base(path, &self.0)
|
|
|
|
|
}
|
|
|
|
|
|
2025-12-22 17:24:17 -08:00
|
|
|
pub fn parent(&self) -> Option<Self> {
|
|
|
|
|
self.0.parent().map(|p| {
|
2026-02-23 21:59:33 -08:00
|
|
|
debug_assert!(
|
|
|
|
|
p.is_absolute(),
|
|
|
|
|
"parent of AbsolutePathBuf must be absolute"
|
|
|
|
|
);
|
|
|
|
|
Self(p.to_path_buf())
|
2025-12-22 17:24:17 -08:00
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
pub fn as_path(&self) -> &Path {
|
|
|
|
|
&self.0
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub fn into_path_buf(self) -> PathBuf {
|
|
|
|
|
self.0
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pub fn to_path_buf(&self) -> PathBuf {
|
|
|
|
|
self.0.clone()
|
|
|
|
|
}
|
|
|
|
|
|
2025-12-12 15:25:22 -08:00
|
|
|
pub fn to_string_lossy(&self) -> std::borrow::Cow<'_, str> {
|
|
|
|
|
self.0.to_string_lossy()
|
|
|
|
|
}
|
|
|
|
|
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
pub fn display(&self) -> Display<'_> {
|
|
|
|
|
self.0.display()
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2025-12-12 15:25:22 -08:00
|
|
|
impl AsRef<Path> for AbsolutePathBuf {
|
|
|
|
|
fn as_ref(&self) -> &Path {
|
|
|
|
|
&self.0
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl From<AbsolutePathBuf> for PathBuf {
|
|
|
|
|
fn from(path: AbsolutePathBuf) -> Self {
|
|
|
|
|
path.into_path_buf()
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl TryFrom<&Path> for AbsolutePathBuf {
|
|
|
|
|
type Error = std::io::Error;
|
|
|
|
|
|
|
|
|
|
fn try_from(value: &Path) -> Result<Self, Self::Error> {
|
|
|
|
|
Self::from_absolute_path(value)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl TryFrom<PathBuf> for AbsolutePathBuf {
|
|
|
|
|
type Error = std::io::Error;
|
|
|
|
|
|
|
|
|
|
fn try_from(value: PathBuf) -> Result<Self, Self::Error> {
|
|
|
|
|
Self::from_absolute_path(value)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl TryFrom<&str> for AbsolutePathBuf {
|
|
|
|
|
type Error = std::io::Error;
|
|
|
|
|
|
|
|
|
|
fn try_from(value: &str) -> Result<Self, Self::Error> {
|
|
|
|
|
Self::from_absolute_path(value)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl TryFrom<String> for AbsolutePathBuf {
|
|
|
|
|
type Error = std::io::Error;
|
|
|
|
|
|
|
|
|
|
fn try_from(value: String) -> Result<Self, Self::Error> {
|
|
|
|
|
Self::from_absolute_path(value)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
thread_local! {
|
|
|
|
|
static ABSOLUTE_PATH_BASE: RefCell<Option<PathBuf>> = const { RefCell::new(None) };
|
|
|
|
|
}
|
|
|
|
|
|
2025-12-22 11:07:36 -08:00
|
|
|
/// Ensure this guard is held while deserializing `AbsolutePathBuf` values to
|
|
|
|
|
/// provide a base path for resolving relative paths. Because this relies on
|
|
|
|
|
/// thread-local storage, the deserialization must be single-threaded and
|
|
|
|
|
/// occur on the same thread that created the guard.
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
pub struct AbsolutePathBufGuard;
|
|
|
|
|
|
|
|
|
|
impl AbsolutePathBufGuard {
|
|
|
|
|
pub fn new(base_path: &Path) -> Self {
|
|
|
|
|
ABSOLUTE_PATH_BASE.with(|cell| {
|
|
|
|
|
*cell.borrow_mut() = Some(base_path.to_path_buf());
|
|
|
|
|
});
|
|
|
|
|
Self
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl Drop for AbsolutePathBufGuard {
|
|
|
|
|
fn drop(&mut self) {
|
|
|
|
|
ABSOLUTE_PATH_BASE.with(|cell| {
|
|
|
|
|
*cell.borrow_mut() = None;
|
|
|
|
|
});
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
impl<'de> Deserialize<'de> for AbsolutePathBuf {
|
|
|
|
|
fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
|
|
|
|
|
where
|
|
|
|
|
D: Deserializer<'de>,
|
|
|
|
|
{
|
|
|
|
|
let path = PathBuf::deserialize(deserializer)?;
|
|
|
|
|
ABSOLUTE_PATH_BASE.with(|cell| match cell.borrow().as_deref() {
|
|
|
|
|
Some(base) => {
|
|
|
|
|
Ok(Self::resolve_path_against_base(path, base).map_err(SerdeError::custom)?)
|
|
|
|
|
}
|
|
|
|
|
None if path.is_absolute() => {
|
|
|
|
|
Self::from_absolute_path(path).map_err(SerdeError::custom)
|
|
|
|
|
}
|
|
|
|
|
None => Err(SerdeError::custom(
|
|
|
|
|
"AbsolutePathBuf deserialized without a base path",
|
|
|
|
|
)),
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
|
mod tests {
|
|
|
|
|
use super::*;
|
2026-01-20 10:55:01 -08:00
|
|
|
use pretty_assertions::assert_eq;
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
use tempfile::tempdir;
|
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn create_with_absolute_path_ignores_base_path() {
|
|
|
|
|
let base_dir = tempdir().expect("base dir");
|
|
|
|
|
let absolute_dir = tempdir().expect("absolute dir");
|
|
|
|
|
let base_path = base_dir.path();
|
|
|
|
|
let absolute_path = absolute_dir.path().join("file.txt");
|
|
|
|
|
let abs_path_buf =
|
|
|
|
|
AbsolutePathBuf::resolve_path_against_base(absolute_path.clone(), base_path)
|
|
|
|
|
.expect("failed to create");
|
|
|
|
|
assert_eq!(abs_path_buf.as_path(), absolute_path.as_path());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn relative_path_is_resolved_against_base_path() {
|
|
|
|
|
let temp_dir = tempdir().expect("base dir");
|
|
|
|
|
let base_dir = temp_dir.path();
|
|
|
|
|
let abs_path_buf = AbsolutePathBuf::resolve_path_against_base("file.txt", base_dir)
|
|
|
|
|
.expect("failed to create");
|
|
|
|
|
assert_eq!(abs_path_buf.as_path(), base_dir.join("file.txt").as_path());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
|
fn guard_used_in_deserialization() {
|
|
|
|
|
let temp_dir = tempdir().expect("base dir");
|
|
|
|
|
let base_dir = temp_dir.path();
|
|
|
|
|
let relative_path = "subdir/file.txt";
|
|
|
|
|
let abs_path_buf = {
|
|
|
|
|
let _guard = AbsolutePathBufGuard::new(base_dir);
|
|
|
|
|
serde_json::from_str::<AbsolutePathBuf>(&format!(r#""{relative_path}""#))
|
|
|
|
|
.expect("failed to deserialize")
|
|
|
|
|
};
|
|
|
|
|
assert_eq!(
|
|
|
|
|
abs_path_buf.as_path(),
|
|
|
|
|
base_dir.join(relative_path).as_path()
|
|
|
|
|
);
|
|
|
|
|
}
|
2026-01-20 10:55:01 -08:00
|
|
|
|
|
|
|
|
#[cfg(not(target_os = "windows"))]
|
|
|
|
|
#[test]
|
|
|
|
|
fn home_directory_root_on_non_windows_is_expanded_in_deserialization() {
|
|
|
|
|
let Some(home) = home_dir() else {
|
|
|
|
|
return;
|
|
|
|
|
};
|
|
|
|
|
let temp_dir = tempdir().expect("base dir");
|
|
|
|
|
let abs_path_buf = {
|
|
|
|
|
let _guard = AbsolutePathBufGuard::new(temp_dir.path());
|
|
|
|
|
serde_json::from_str::<AbsolutePathBuf>("\"~\"").expect("failed to deserialize")
|
|
|
|
|
};
|
|
|
|
|
assert_eq!(abs_path_buf.as_path(), home.as_path());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[cfg(not(target_os = "windows"))]
|
|
|
|
|
#[test]
|
|
|
|
|
fn home_directory_subpath_on_non_windows_is_expanded_in_deserialization() {
|
|
|
|
|
let Some(home) = home_dir() else {
|
|
|
|
|
return;
|
|
|
|
|
};
|
|
|
|
|
let temp_dir = tempdir().expect("base dir");
|
|
|
|
|
let abs_path_buf = {
|
|
|
|
|
let _guard = AbsolutePathBufGuard::new(temp_dir.path());
|
|
|
|
|
serde_json::from_str::<AbsolutePathBuf>("\"~/code\"").expect("failed to deserialize")
|
|
|
|
|
};
|
|
|
|
|
assert_eq!(abs_path_buf.as_path(), home.join("code").as_path());
|
|
|
|
|
}
|
|
|
|
|
|
2026-01-21 10:43:10 -08:00
|
|
|
#[cfg(not(target_os = "windows"))]
|
|
|
|
|
#[test]
|
|
|
|
|
fn home_directory_double_slash_on_non_windows_is_expanded_in_deserialization() {
|
|
|
|
|
let Some(home) = home_dir() else {
|
|
|
|
|
return;
|
|
|
|
|
};
|
|
|
|
|
let temp_dir = tempdir().expect("base dir");
|
|
|
|
|
let abs_path_buf = {
|
|
|
|
|
let _guard = AbsolutePathBufGuard::new(temp_dir.path());
|
|
|
|
|
serde_json::from_str::<AbsolutePathBuf>("\"~//code\"").expect("failed to deserialize")
|
|
|
|
|
};
|
|
|
|
|
assert_eq!(abs_path_buf.as_path(), home.join("code").as_path());
|
|
|
|
|
}
|
|
|
|
|
|
2026-01-20 10:55:01 -08:00
|
|
|
#[cfg(target_os = "windows")]
|
|
|
|
|
#[test]
|
|
|
|
|
fn home_directory_on_windows_is_not_expanded_in_deserialization() {
|
|
|
|
|
let temp_dir = tempdir().expect("base dir");
|
|
|
|
|
let base_dir = temp_dir.path();
|
|
|
|
|
let abs_path_buf = {
|
|
|
|
|
let _guard = AbsolutePathBufGuard::new(base_dir);
|
|
|
|
|
serde_json::from_str::<AbsolutePathBuf>("\"~/code\"").expect("failed to deserialize")
|
|
|
|
|
};
|
|
|
|
|
assert_eq!(
|
|
|
|
|
abs_path_buf.as_path(),
|
|
|
|
|
base_dir.join("~").join("code").as_path()
|
|
|
|
|
);
|
|
|
|
|
}
|
fix: introduce AbsolutePathBuf and resolve relative paths in config.toml (#7796)
This PR attempts to solve two problems by introducing a
`AbsolutePathBuf` type with a special deserializer:
- `AbsolutePathBuf` attempts to be a generally useful abstraction, as it
ensures, by constructing, that it represents a value that is an
absolute, normalized path, which is a stronger guarantee than an
arbitrary `PathBuf`.
- Values in `config.toml` that can be either an absolute or relative
path should be resolved against the folder containing the `config.toml`
in the relative path case. This PR makes this easy to support: the main
cost is ensuring `AbsolutePathBufGuard` is used inside
`deserialize_config_toml_with_base()`.
While `AbsolutePathBufGuard` may seem slightly distasteful because it
relies on thread-local storage, this seems much cleaner to me than using
than my various experiments with
https://docs.rs/serde/latest/serde/de/trait.DeserializeSeed.html.
Further, since the `deserialize()` method from the `Deserialize` trait
is not async, we do not really have to worry about the deserialization
work being spread across multiple threads in a way that would interfere
with `AbsolutePathBufGuard`.
To start, this PR introduces the use of `AbsolutePathBuf` in
`OtelTlsConfig`. Note how this simplifies `otel_provider.rs` because it
no longer requires `settings.codex_home` to be threaded through.
Furthermore, this sets us up better for a world where multiple
`config.toml` files from different folders could be loaded and then
merged together, as the absolutifying of the paths must be done against
the correct parent folder.
2025-12-09 17:37:52 -08:00
|
|
|
}
|