Meanwhile due to lack of that variable substitution we are attempting to push all of our cargo configuration through overriding env vars rather than having the option of embedding a few environment variables within .cargo/config.
It would aid ease of use and roll out of rust to corporate environments if already predefined environment variable could be used. CIs are ok as setting lots of env vars is what they are good at, but for teams of devs working on a project it's a pain point that I don't really think needs to be there.
I'm raising this because it seems like a niggle that we have to find work arounds for - I hit it once every couple of months. I'd rather we fixed the problem rather than everyone work around the lack of environment variable substitution.
For me passing through linker args via rustflags in .cargo/config is something we'd like to do for pyo3 as one example. We would like to have used it for proxy setup as another case in point and also when we were isolating ourselves from crates.io there were times that it would have been helpful too.
I don't know of any other major build systems that don't support env vars, and I appreciate that they can be overused (we could have a defaulting mechanism? - we don't need to just accept the way bash does things).
This is rust land, somehow can we have our cake and eat it?
Splicing arbitrary text into a package config file smells like a security nightmare, all things aside.
By the way, the specific doc-version problem mentioned above is already mitigated by the fact that docs.rs redirects to the latest version, there's no need to include the version string in the URL.
I don't see the security difference to the current policy of overide all things via an environment variable? I would argue it was a preferable alternative as only expected things might be overridden rather than the current blanket policy - but I'm not proposing that we remove the setting of config via CARGO_ - just that with env vars being available to be used within config the CARGO_ overrides would probably be used a lot less.
I would assume that we would want to stay hygenic and that a substitution couldn't 'break out' of its container like good ol bobby drop tables. ( https://xkcd.com/327/ )
The user experiance of CARGO_ env vars is not great - if anything is miss spelled they are silently ignored.
If we could insert env vars then we could optionally have defaults. If no default was specified then rather than assuming empty string if undefined we could give a nice error message that a certain env var needs to be set.
E.g. $(ENV_VAR|A_default) with some encoding if you wanted a ')'