Is it easy to remove "crate::~" from generated code?

[soarcreator]

I think it is better to remove "crate::~" from generated Rust code because I cannot move the generated codec file to wherever I want to put the file in my project.
My suggestion is to use "super::" instead, or use "use" statement for sibling module in each top mod and remove "crate::schema_capnp::".

I tried to customize this plugin like above, but I cannot figure out how to customize "schema_capnp.rs" file in an instant, which I'm guessing is the important part for this issue.

[dwrensha]

You can put the generated code wherever you want by using the Rust.parentModule annotation. Does that work for you?

[sum-elier]

You can put the generated code wherever you want by using the Rust.parentModule annotation. Does that work for you?

Thanks for the pointer, @dwrensha, there was no mention of that in the README, I suggest adding it :).

I ended up using the feature as follows (rust.capnp is next to my schemas):

using import "rust.capnp".parentModule;

$parentModule("my::parent::module");

Nonetheless the downside is that your schema is now tied to the internal structure of you project, which won't necessarily remain so forever. In fact, if one wants to reuse the same schema across different code bases one has to change annotation every time.
I am completely unaware of the effort required to implement @soarcreator's suggestion, but seems the most convenient API wise.

[dwrensha]

Aside from the implementation difficulty of using relative paths, here's another reason I prefer absolute paths in the generated code. Suppose that you have two schemas foo.capnp and bar.capnp and you want to include them in your crate like this:

mod a {
   mod b {
       mod foo_capnp { /* ... generated code */ }
   }
  
  mod bar_capnp { /* ... generated code */ }
}

Suppose moreover that bar.capnp imports foo.capnp and uses some of the types from it.

I don't see a way to make that work if the generated code relies on relative paths. How would the bar_capnp generated code know about the b module?

---

To take this a step further, imagine that you could import across crate boundaries. Then you could factor your common schema into its own crate, and all downstream users of it would just need to include it as a Cargo dependency and import it in their schemas, without needing to perform a duplicate codegen step.

I believe that is the ideal world we should be striving for.

To get it to work, we'll need to add crate annotation to rust.capnp

annotation crate (file) :Text;

and we'll need Cargo to support something like rust-lang/cargo#3544.

[sum-elier]

Is the parentModule documented somewhere?

[dwrensha]

Currently, the only documentation is inline:

capnproto-rust/capnpc/rust.capnp

Line 17 in d58b59d

annotation parentModule @0xabee386cd1450364 (file) :Text;

I agree that it would be good to add some documentation elsewhere.

[spacekookie]

I just stumbled across this problem and I'd kinda expect the CompilerCommand invocation in build.rs to have a builder function I can set to override the path in my project. Anything else just seems obscure. Is there a way to implement it there?

[dwrensha]

Yes, I think that would be possible. The new option could be named default_parent_module, and it could apply whenever the Rust.parentModule annotation is not present.

However, I'm a little bit worried that such an option might interact poorly with schemas that have cross-crate dependencies. If a schema from crate A wants to import some types from a schema defined in crate B, how will it know the Rust path at which to expect the imported types? (Admittedly, my worry here is rather abstract, because rust-lang/cargo#3544 is blocking cross-crate capnp schema dependencies from actually working.)

[dwrensha]

Thank you everyone for the input. I have added a CompilerCommand::default_parent_module() option in 1928fdd.
It is available in capnpc-v0.14.2.