any chance of having something like #[serde(crate = "...")] for thiserror?

[hmacias-avaya]

I'm trying to use the latest thiserror 2 and until now I was reexporting thiserror from a common dependency so my "end project" was not depending on thiserror directly.
Now this is no longer possible and is mentioned on the breaking changes section:

Code containing invocations of thiserror's derive(Error) must now have a direct dependency on the thiserror crate regardless of the error data structure's contents

is there any chance of having something like serde's 'crate' annotation in order to be able to use thiserror derives without depending on thiserror directly?
https://serde.rs/container-attrs.html#crate

This seems to work nicely when using serde's derives; perhaps it could work here as well?

[dtolnay]

I would prefer not to support this.

[j-a-m-l]

@hmacias-avaya as an alternative you could try something like this:

External lib common_lib:

pub use thiserror::*;

And then trick thiserror to use the common library:

extern crate common_lib as thiserror;

[hmacias-avaya]

thanks, I'll give it a try.

[Kitt3120]

@hmacias-avaya as an alternative you could try something like this:

External lib common_lib:

pub use thiserror::*;

And then trick thiserror to use the common library:

extern crate common_lib as thiserror;

At first I thought that it works, vs code does not show any errors using rust-analyzer. But when compiling, it fails:

use thiserror::Error;

#[derive(Debug, Error)]
pub enum TestError {
    #[error("Test {0}")]
    PleaseWork(String),
}

error: cannot find attribute `error` in this scope
   --> src/types.rs:124:7
    |
124 |     #[error("Test {0}")]
    |       ^^^^^

For more information about this error, try `rustc --explain E0432`.

So, I can just say that I'd also love to have this feature. I am unaware of how this affects the code exactly. If it makes things very complicated and way harder to maintain, it's not worth it, of course. But if that's not the case, I kindly ask for this feature again.

[dtolnay]

If anyone would like to work on this, rust-lang/rust#54363 (comment) has a writeup of my preferred approach.