Support environment variable expansion in config.toml
#10789
Comments
avdb13
added
the
C-feature-request
|
AFAIK, Cargo does not support environment variable expansion like shell does in most fields of its configuration file at this moment. Environment variable expansion is a big topic containing lots of different syntax flavours and mechanisms. Not to mention the interaction with Alternatively, you may circumvent it with the following approaches:
Hope it help :) |
weihanglo
added
A-configuration
weihanglo
changed the title
config.tomlconfig.toml
|
Pardon for my editing the issue title. This should make the intent slightly prominent. |
bpf-rs & bpf-feature tests need capabilities (to read certain directories or load bpf programs) that are not available to a regular user. This is strictly possible by just wrapping `cargo test` with `sudo` (such as with `sudo -E "PATH=$PATH" $(which cargo) test --all-features`) but the issue here (besides ergonomics) is when cargo tests build & write new files they are now owned by root (making future non-sudo builds fail). It might be possible to configure sudo to strictly write new files as a separate user from root but I haven't seen that. Ideally, we just run the created test bins with sudo after compilation and this is possible with specifying a runner in .cargo/config.toml. We can specify this at the workspace level for the relevant target triple but the issue with this is that sudo disallows certain libraries to be dynamically linked which the proc_macro crate (used transitively by bpf-rs-macros) needs. So we're left with the option of forcing sudo to allow loading of these libraries or to only using sudo on the crate tests that need it. The problem is that cargo itself changes LD_LIBRARY_PATH: https://doc.rust-lang.org/cargo/reference/environment-variables.html#dynamic-library-paths which we don't have access to from the runner's perspective, especially given that variable shell expansion is not supported: rust-lang/cargo#10789 For now, we're choosing the latter (only using sudo on specific crates) but we ran into another issue: config.toml is ignored on a per-crate basis when running cargo test from a workspace. To workaround this, we change our local task `just test` to cd into each crate and run tests from there. This is not ideal but gets the job done for now. We keep our github actions to just run all the tests as the original sudo cmd for now since we don't care about the owners of the new files after the vm disappears. Related to #7 Signed-off-by: Milan <milan@mdaverde.com>
|
I have another use case for this. I'd like to set the value of an environment variable in I'm not entirely sure, however, if the variables would even be available at the time of evaluation. So this might be a slightly harder problem to solve in that case. |
|
@weihanglo this combined with #10273 adds a lot of capability to the configuration system. We'd be able to use environment variables within expressions (this issue) and also set them conditionally (#10273). |
|
@weihanglo Is there a tracking issue/RFC of sorts regarding this? I ask because I've only ever seen everything decided in a "solid" manner in rust community (except async lol IMHO) and would love to read all the nuances. (And of course i'm also suffering from a lack of env var support in both Cargo.toml and .cargo/config.toml) Talking specifically about #10789 (comment) |
|
@asdf8dfafjk AFAIK no. This is probably the only place to discuss environment variable expansion I am aware of. There might be place like URLO having such a discussion. If you are going to bake an RFC from your side, kindly recommend following the guide. |
|
@weihanglo Sadly both my knowledge and rigor wouldn't be up to rust's standard's. My motivation behind asking the question was a curiousity about the nuances of environment variables but upon further thought I suspect there is also an issue of config variable evaluation in a way that is not confusing. On that note, here's a library https://github.com/japgolly/clear-config that seems to be well liked in the scala ecosystem (it can serve as a good inspiration) |
|
I think this is also related to #8801 in a way |
weihanglo
added
the
S-needs-design
|
If we decide to have some kind of expansion (environment variable or otherwise), we should mark things that get expanded, rather than just allowing |
Problem
Currently, the following doesn't seem to work, it gets resolved to a relative path without parsing the environment variable:
Proposed Solution
match the filepath strings in Cargo with regex to find the environment variables.
Notes
No response
The text was updated successfully, but these errors were encountered: