WIP: Thoughts on #2458

[kinnison]

This is me starting to think about fixing #2458

I'm mostly putting it up so we can discuss the approach and see if it's sufficient. Right now it's not tested.

[workingjubilee]

So, hm, at least 1 problem:

1. The rust-toolchain file is specified as "yes, this has to be USASCII." But path names are not necessarily USASCII. USASCII is a subset of UTF8 however, so we're almost OK. But Windows paths are very not UTF8 by default. And I know what a BOM is but many of your users don't.

2. Further, I think a "path" and a "channel" describe what is mostly the same concept ("what point in timespace am I getting my Rust toolchain from?") and this should be clarified somewhat.

For instance, I can see users requesting "how about I use rust-toolchain to set my own local interpretation of both stable and nightly so that I can use $proxy +stable or $proxy +nightly?" That can be denied, of course, but if it is, then I think we should still have a principled approach here, I guess is what I am saying? So if that doesn't work, then we should assign an ident to rust-toolchain's override like +local or +path.

[kinnison]

I think the intent is that the USASCII encoding requirement will be lifted for the toml form of the rust-toolchain because that assumes utf8 encoding anyway AIUI. Given that, I suppose we could restrict the path form to the toml rather than the single-line variant; however the single-line variant gains (potentially un-advertised) support by dint of supporting cargo +/path/too/rust build type constructs which I would want to support.

Paths and channels are subtly different because channel is something which can update over time, whereas path is just some bytes on a filesystem.

Thanks for your input though, it's food for thought, for sure.

[kinnison]

Obsoleted by #2678