Variable Interpolation In Cargo toml - Part II

Continuing on from the earlier discussion:

Cargo is a wonderful package manager, but plese can we use env variables to configure it?

'boats was concerned that toml might later include an environment variable substitution layer. This was ruled out in 2014 ( https://github.com/toml-lang/toml/issues/255 ) and again in 2017 ( https://github.com/toml-lang/toml/issues/496 ). I think we can conclude that toml is not as a standard going to adopt environment variable substitution any time soon.

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 ')'

Indeed seems legit. I suggest one could use external jinja template lije Cargo.toml.j2 and simple python script to regenerate cargo toml.

not so correct, if library users downloaded the previous version they would want to get a link to exact version's docks.