2 ms·
Cargo people are working on single-file "Rust script" support that would allow embedding the necessary parts of the manifest (Cargo.toml) directly in the .rs fi
by Sharlin 2y ago
Cargo people are working on single-file "Rust script" support that would allow embedding the necessary parts of the manifest (Cargo.toml) directly in the .rs file as special doc comments (so things are transparent to rustc): [0]
[0] https://rust-lang.github.io/rfcs/3424-cargo-script.html https://rust-lang.github.io/rfcs/3424-cargo-script.html
- jrochkind1 2y agoYou can already do that with ruby bundler (which perhaps inspired it) https://bundler.io/guides/bundler_in_a_single_file_ruby_script.html https://bundler.io/guides/bundler_in_a_single_file_ruby_scri... But I recognize that isn't quite what the questioner is asking, because at least in ruby you are still going to need "require" statements (unless you have an autoloader) to actually load the code, the inline `gemfile` specifies your dependencies, which is different than a require/import statement to actually load code from possibly one of those dependencies.
- epage 2y agoWhat 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