jmgilman / rustify Goto Github PK

The documentation strongly suggests that the content-type is set to JSON, but this doesn't happen anywhere!

We're using the following middleware … but it would be nice if it was included by default.

pub struct ContentTypeMiddleware;

impl MiddleWare for ContentTypeMiddleware {
    fn request<E>(
        &self,
        _: &E,
        req: &mut http::request::Request<Vec<u8>>,
    ) -> Result<(), ClientError>
    where
        E: Endpoint,
    {
        req.headers_mut()
            .append("content-type", HeaderValue::from_static("application/json"));

        Ok(())
    }

    fn response<E>(
        &self,
        _: &E,
        _: &mut http::response::Response<Vec<u8>>,
    ) -> Result<(), ClientError>
    where
        E: Endpoint,
    {
        Ok(())
    }
}

Would you be open to a PR adding this default behaviour?

Rust RFC 3373: Avoid non-local definitions in functions was accepted and it's implementation at rust-lang/rust#120393 found that this crate would be affected by it.

To be more precise users of this crate would be affected by it, in the form of a warn-by-default lint: non_local_definitions. This is because the derive macros from this crate use impl in a local context, const _DERIVE_Endpoint_FOR_???:

Fortunately I believe a simple fix exist for this crate, by using a const-anon instead of named one (since const-anon are specialized to be "transparent" to their parent):

-    let const_name = format!("_DERIVE_Endpoint_FOR_{}", id);
-    let const_ident = Ident::new(const_name.as_str(), Span::call_site());
     quote! {
-        const #const_ident: () = {
+        const _: () = {

I would suggest applying some form of the patch above as well as releasing a patch version of this crate, as to have a fix available for users before or just after the PR is merged.

cc @jmgilman

difference is unmaintained

The author of the difference crate is unresponsive.

Maintained alternatives:

• dissimilar

• similar

• treediff

• diffus

See advisory page for additional details.

The release 0.5.4 includes changes from #17 where the requirement for http was changed from ^0.2.6 to ^1.0.0.

These are breaking changes because http is a public dependency (its types are leaking into the types defined by rustify) so applying a major semver requirement change on http propagates to rustify.

As an example, this now breaks vaultrs which currently depends on rustify: ^0.5.2 and http: ^0.2.9 and assumes unification between its http version and the one from rustify. See jmgilman/vaultrs#91

I recommend the following actions:

• rustify 0.5.4 should be yanked immediately
• rustify 0.6.0 should be released
• Optional: All public dependencies should be re-exported at the lib root and consumers should avoid relying on implicit cargo version unification

Consider case where I want to add new user to endpint '/users'

POST /users/ 

{
    "name": "foobar"
}

I have a common code base that I cannot modify, but it has the definition of User. I would like have the option like serde(flatten):

use common::User;

#[derive(Debug, Clone, Endpoint)]
#[endpoint(
    path = "/users",
    method = "POST",
    response = "()"
)]
struct CreateUser {
    #[endpoint(flatten)]
    user: User
}