Server should resolve file based config relative to file's location #711
Comments
alcarney
added
bug
alcarney
added a commit
to alcarney/esbonio
that referenced
this issue
Jul 7, 2024
Configuration objects can now accept variables of the form `${variable}`
and have them expanded by the configuration system at runtime.
This commit adds support for the following variables
- `${scope}`: The full uri of the scope at which the configuration
object was requested
- `${scopePath}`: The path component of the scope uri
- `${scopeFsPath}`: The path component of the scope uri as a
filesystem path
Currently these configuration variables will only be expanded if they
appear in a field that is a simple string.
Additionaly, this commit sets the default value for `SphinxConfig.cwd`
to be `${scopeFsPath}`. This should mean that any
`esbonio.sphinx.buildCommand` values in a `pyproject.toml` file will
be evaluated relative to the file's location. Closes swyddfa#711
alcarney
added a commit
to alcarney/esbonio
that referenced
this issue
Jul 7, 2024
Configuration objects can now accept variables of the form `${variable}`
and have them expanded by the configuration system at runtime.
This commit adds support for the following variables
- `${scope}`: The full uri of the scope at which the configuration
object was requested
- `${scopePath}`: The path component of the scope uri
- `${scopeFsPath}`: The path component of the scope uri as a
filesystem path
Currently these configuration variables will only be expanded if they
appear in a field that is a simple string.
Additionaly, this commit sets the default value for `SphinxConfig.cwd`
to be `${scopeFsPath}`. This should mean that any
`esbonio.sphinx.buildCommand` values in a `pyproject.toml` file will
be evaluated relative to the file's location. Closes swyddfa#711
alcarney
added a commit
to alcarney/esbonio
that referenced
this issue
Jul 7, 2024
Configuration objects can now accept variables of the form `${variable}`
and have them expanded by the configuration system at runtime.
This commit adds support for the following variables
- `${scope}`: The full uri of the scope at which the configuration
object was requested
- `${scopePath}`: The path component of the scope uri
- `${scopeFsPath}`: The path component of the scope uri as a
filesystem path
Currently these configuration variables will only be expanded if they
appear in a field that is a simple string.
Additionaly, this commit sets the default value for `SphinxConfig.cwd`
to be `${scopeFsPath}`. This should mean that any
`esbonio.sphinx.buildCommand` values in a `pyproject.toml` file will
be evaluated relative to the file's location. Closes swyddfa#711
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider the following config from this repo
esbonio/docs/pyproject.toml
Lines 1 to 2 in 8e1340a
From a user's perspective it would be nice if the paths
.and./_buildwere resolved relative to the file's location (${workspaceFolder}/docs), rather than the current behavior where they are resolved relative to${workspaceFolder}.The trick is making that information available in the right place, since where the configuration value is sourced from is currently hidden from the code that uses the result - (which is by design)
The text was updated successfully, but these errors were encountered: