What cargo is doing is something like #!/usr/bin/env cargo --- [dependencies] regex = "1" --- fn main() { } I think this is propo

What cargo is doing is something like #!/usr/bin/env cargo --- [dependencies] regex = "1" --- fn main() { } I think this is proposing something like #!/usr/bin/env cargo #[version = "1"] extern regex; fn main() { } though `extern` has gone out of style and would instead be something like #!/usr/bin/env cargo #[version = "1"] use regex; fn main() { } but that wouldn't isn't idomatic either and so you would have #!/usr/bin/env cargo #[version = "1"] use regex::RegexBuilder; use regex::Regex; fn main() { } which runs into the problem noted but in one file > I realize there would be downsides to this idea. For example, you have to figure out what happens if different versions of a requrement are specified in different files of the same package (in a sense, the concept of "package" starts to weaken or break down in a case like that). But in some cases, e.g. a single-file python script, it seems like it would be great. To fully support this, we'd need a top-down compilation model like Zig so we could discover dependencies in the current project. Today, we have to do bottom-up compilation, knowing all dependencies a priori. A downside to any of this is it is expensive to do any any dependency management - Introspecting dependencies requires parsing every file in every part of your dependency tree - Editing dependencies requires walking every file in your project