Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add custom parser support to Env provider #119

Open
felipou opened this issue Aug 22, 2024 · 5 comments
Open

Add custom parser support to Env provider #119

felipou opened this issue Aug 22, 2024 · 5 comments

Comments

@felipou
Copy link

felipou commented Aug 22, 2024

Hi! First of all, thanks for this awesome crate!

I wanted some flexibility in the format of the environment variable values when using the Env provider, so I did a little experiment, and it seems it would be easy to implement an option to setup a custom parser in the Env provider:

felipou@67e0551

It needs some work, but in the tests you can see how we could easily support YAML or JSON values for example, and it would be optional, without breaking compatibility.

Does this feature make sense? Should I polish it and create a pull request?

@SergioBenitez
Copy link
Owner

Yeah! That's totally useful. Please do!

@felipou
Copy link
Author

felipou commented Aug 23, 2024

Great! I'll add proper documentation to the new parser method (any other suggestions for that name? I'm not totally convinced it's a good option) and some more tests.

Also, I was in doubt about what I did to the cloneable_fn_trait macro (by the way, very clever solution to the clonable box dyn), do you have any other suggestions as to what to do there? Basically the Cloneable trait which is created by this macro caused a conflict when using the macro twice, so I added the custom name for that trait as an option to the macro, but what I really wanted was to have just one trait declared, and reused... as I've written this, now I'm thinking of decomposing that macro and have one that just assumes there is an existing Cloneable trait in scope already. I'll experiment with this!

@SergioBenitez
Copy link
Owner

Basically the Cloneable trait which is created by this macro caused a conflict when using the macro twice,

You can invoke the macro inside of a module to give the resulting items different namespaces:

mod foo {
    crate::util::cloneable_fn_trait!(..);
}

mod bar {
    crate::util::cloneable_fn_trait!(..);
}

@felipou
Copy link
Author

felipou commented Aug 26, 2024

I actually tried that before, but it didn't work because the trait is not public, so I'm thinking of just adding the pub option to the macro?

@@ -327,6 +327,11 @@ macro_rules! make_cloneable {
 #[doc(hidden)]
 #[macro_export]
 macro_rules! cloneable_fn_trait {
+    (pub $Name:ident: $($rest:tt)*) => {
+        pub trait $Name: $($rest)* + Cloneable + 'static { }
+        impl<F: Clone + 'static> $Name for F where F: $($rest)* { }
+        $crate::make_cloneable!($Name: Cloneable);
+    };
     ($Name:ident: $($rest:tt)*) => {
         trait $Name: $($rest)* + Cloneable + 'static { }
         impl<F: Clone + 'static> $Name for F where F: $($rest)* { }

I actually just tried this, and it worked well, I'll create the PR as soon as I finish documenting the "parser" method.

@felipou
Copy link
Author

felipou commented Sep 4, 2024

Just created the PR: #121

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants