kangalio

> This wrapping should be done by the user with their own error type. Even if a user just depends on the default error type (Box), they can downcast to...

> We can't add a From implementation for Error to return Error::User, because it would conflict with the From for T impl from the standard library (as Error implements std::error::Error)....

I have successfully fixed this in my local framework fork. It's based upon #25 so I haven't created a PR yet (that would be a little messy, a PR blocked...

I'm hitting this on Arch Linux despite having [`ffmpeg4.4`](https://archlinux.org/packages/extra/x86_64/ffmpeg4.4/) installed. How to redirect composer to use ffmpeg4.4 instead?

Yep, I tried it out immediately after ooshlablu made it. With exception of the Play button, it works :)

> Arguably the `with` attribute does two separate things here. First it generates the normal `impl Deserialize` into `DeserializeImpl` and second it implements `Deserialize` using `some_module::deserialize`. Could it be worthwhile...

But really, having an identical 2nd copy of the Deserialize trait seems like a hack. How about this approach instead: ```rust #[derive(serde::Deserialize)] #[serde(deserialize_with = "deserialize_foo")] struct Foo {} fn deserialize_foo>(...

@jonasbb [pointed out](https://discord.com/channels/273534239310479360/818964227783262209/1042437268717187114) an existing serde feature that covers this issue: `#[serde(remote = "Self")]`. Adding `#[serde(remote = "Self")]` to a struct with Deserialize/Serialize derive changes the generated deserialize and serialize...

> Isn't the initial post about _not_ implementing `Deserialize` manually, but having it auto-generated with the use of `some_module`? @fjarri No, the issue is only about not implementing the bulk...

Using the original proposed API: ```rust #[derive(Deserialize)] #[serde(with="some_module")] enum SomeEnum { /* any fields here */ } mod some_module { fn deserialize>(deserializer: D) -> Result { ::deserialize(deserializer) } } ```...