Cool, thanks for packaging it. May I alert you whenever I cut a new release (should be extremely low frequency if ever)? My only concern is a one-time-enthusiasm-driven package ever bitrotting after its creation. I've been on both ends of this.
So I understood the issue just fine, we just disagree on what's an acceptable solution. If we were to hash this out in person / in chat I imagine the conversation would go down like this:
A: Using environment variable for build configuration is no good.
B: Why? It's a cross-platform convention, and it's basically the only option that works.
A: But I can't use env var with rust-analyzer (or some other tool).
B: Why not? Just start VSCode (or some other encompassing tool) with the env var.
A: I don't want to restart VSCode to add/change an env var.
B: Okay, then it's something to be solved in VSCode/rust-analyzer/whatever, here's someone else's patch to solve it.
A: It's not merged. / What about some other tool that I'll possibly use?
B: Okay... Back to "it's the basically the only option that works". Solve it in cargo instead.
A: It doesn't have enough traction. How about an ad hoc solution right here.
B: Okay... What's that?
A: An ad hoc config file that has to live in tree to work. I know, it doesn't work when the lib is used as a dependency (99.9% of use cases) unless the dependency is patched.
B: ...
I guess I'll give it another consideration if and when there's an ad-hoc *working* solution that does not require unpacking this crate into <s>filesystem</s> a working tree?
Realistically though, I'll probably reject the ad-hoc working solution as well. A non-standard config file is just too arbitrary. environment.json you say? Never heard of it, and JSON is a shitty config format (it really is). What about JSONC (JSON with comments, and equally importantly, trailing commas)? YAML? TOML? .env? I'm usually not one to settle on something random, but at the same time, I'm not willing to have a debate about config formats when it's a debate that should happen elsewhere (cargo).
Parting thought:
> Environment variables are often an unrelaible and inflexible mechanism for configuring software... There aren't that many crates that require similar environment variables for configuration
Of course you hardly ever need env vars for configuring pure Rust crates. But when it comes to system/C interfacing, using env vars is pretty common. bindgen, clang-sys, cc, etc. these cornerstone crates all use env vars. Probably need to convince them first before asking me to depart from tradition.
(I assumed you're on Windows since I never needed `FFMPEG_DIR` on *nixes -- which I now realize might not be the case -- so the test above was done in PowerShell, but the equivalent should definitely work on macOS/Linux.)
You linked to quite a few long discussion threads and I didn't have time to check them all. Anyway, adding support for a nonstandard, rather random configuration file is definitely not the way to go.
I just checked, setting the env var before launching VSCode seems to work totally fine for me:
```pwsh
$ $env:FFMPEG_DIR="C:\path\to\ffmpeg"
$ code .
```
(rust-analyzer then picks up `FFMPEG_DIR` and builds without problem.)
I guess this way you'll need to relaunch Code every time you want to change `FFMPEG_DIR`, but doesn't sound like a huge pain to me?
I also recommend following a solution like https://github.com/rust-analyzer/rust-analyzer/pull/6099 which solves the problem of setting env vars in rust-analyzer. I'd say tooling inconveniences should be solved in tooling, not by polluting code that tooling's supposed to support. Every project coming up with their own ad hoc hacky solution is untenable.
I'll leave this open for a while in case I'm misunderstanding the issue somehow, and you can enlighten me.