Feature request: YAML as compile-time only dependency

[epage]

Issue by devinrsmith
Sunday Feb 17, 2019 at 14:54 GMT
Originally opened as clap-rs/clap#1416

---

I think that the YAML dependency could be a compile-time only dependency. That would be the best of both world IMO - keep the source neat and tidy, no need for runtime parsing of the parser, and no runtime YAML dependency!

build-scripts
code generation / build-dependencies

[epage]

Comment by Kage-Yami
Saturday Jan 04, 2020 at 12:48 GMT

---

I was also thinking along these lines, but after reading Specifying Dependencies -> Build dependencies, don't they only apply to build.rs (and in fact specifically don't apply to the app itself)? If so, then I don't see how this would work, as I would think the CLI definition needs to happen in the app, rather than a build script...

[epage]

Comment by CreepySkeleton
Sunday Jan 05, 2020 at 05:10 GMT

---

@Kage-Yami is right here, dev-depandencies are exposed only to the build script, the app has no access to them. This is not doable, at least not with current API.

[epage]

Comment by CreepySkeleton
Thursday Feb 06, 2020 at 09:17 GMT

---

We can actually make a proc-macro that parses .yaml and expands to resulting clap::App, no runtime cost involved!

[epage]

Comment by pksunkara
Thursday Feb 13, 2020 at 07:40 GMT

---

The main concern with a proc-macro that parser .yaml is custom spans. For example, let's assume we have a proc-macro load_yaml that builds an App out of yml file. And if the yml file has an error, we should emit a proc-macro-error pointing to the issue which is difficult without us being able to build custom spans (since we won't be tokenizing yml file directly but instead reading the file from fs).

Can we use serde to change something about how we can load the yml during compile time?

NOTE: I looked at the related code, and it looks like current yaml is a run time dependency because it's loading yaml from the yml static string (expanded by include_str!).

[epage]

Comment by CreepySkeleton
Thursday Feb 13, 2020 at 08:39 GMT

---

We can't exactly point there indeed, just because files included via include*! or non-rs files don't really have span info attached to them. What we can do is to print line/column the error was encountered at, and I think it should be "good enough". serde would grant us this info out of box.

[epage]

Comment by pksunkara
Thursday Feb 13, 2020 at 09:04 GMT

---

Yeah, but can we create a span with the line, column info? That would make the error reporting easy

[epage]

Comment by CreepySkeleton
Thursday Feb 13, 2020 at 09:20 GMT

---

We can't create a span with a custom line/column info since the only ways are call_site, def_site, mixed_site. We can't set this info on already existing span because there's no such API, even unstable.

Could you explain what you expect from such API? The error cannot be rendered for files that are not part of a crate.

[epage]

Comment by pksunkara
Thursday Feb 13, 2020 at 20:52 GMT

---

We can't set this info on already existing span because there's no such API, even unstable.

I wanted to make up Span. For files that can not be token streams, but we still want to parse, I wanted to make up Span when I get error and let compile_error! or Diagnostic API take care of printing it for me.

So, I looked into it and proc_macro2 stores the source map locally and thus we can't fool it by making up Span.

[epage]

Comment by pickfire
Saturday Feb 29, 2020 at 01:13 GMT

---

Is const able to help to compile this during compile time? https://github.com/rust-lang/rfcs/blob/master/text/0246-const-vs-static.md

[epage]

Comment by CreepySkeleton
Saturday Feb 29, 2020 at 04:40 GMT

---

@pickfire Nope, since yaml loader is not const at all. We need a proper procedural macro for that.