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

Adding CustomFn layer #34

Merged
merged 5 commits into from
Jun 26, 2023
Merged

Adding CustomFn layer #34

merged 5 commits into from
Jun 26, 2023

Conversation

luketpeterson
Copy link
Contributor

Adding CustomFn layer, where any Fn type, (function or immutable closure) can provide config values.

This is useful to support additional data sources, for example to get values from a database or from an unsupported file format, e.g. hjson (https://crates.io/crates/deser-hjson)

Thank you.

…sures) can provide a values. This is useful to support additional data sources, for example a database or an unsupported file format, e.g. hjson
@luketpeterson
Copy link
Contributor Author

Here is a code excerpt from the test, to see the usage:

    #[config]
    #[derive(Debug, Default)]
    struct TestCfg {
        test: String,
        another: usize,
    }

    std::env::set_var("ANOTHER", "5");

    let func = || {
        to_value(TestCfg{test: "from func".to_string(), another: 25}).unwrap()
    };

    let prio = vec![Layer::CustomFn(func.into()), Layer::Env(None)];
    let config = TestCfg::with_layers(&prio).unwrap();
    assert_eq!(config.test, String::from("from func"));
    assert_eq!(config.another, 5usize);

…irement on the closure makes an Fn version no better than a static fn.

Fixing a wrong doc comment
@bnjjj
Copy link
Owner

bnjjj commented Jun 21, 2023

Hey @luketpeterson it looks great ! Thank you ! Could you just document it in the README here to let users know that layer exists. Thanks a lot

@bnjjj
Copy link
Owner

bnjjj commented Jun 21, 2023

(tests are failing too)

@luketpeterson
Copy link
Contributor Author

The test issue is that the set of features enabled by the github action (equivalent to running cargo test --features "clap, clap_rs, default, dhall, env, envy, ini, json, serde_dhall, serde_ini, serde_yaml, toml, toml_rs, yaml") doesn't include the new feature I added, "custom_fn", however it's still running the custom_fn test.

However, the same situation exists for nearly all the optional features. For example, invoking cargo test without the toml feature specified causes the toml tests to fail.

@luketpeterson
Copy link
Contributor Author

I could conditionally exclude the test (as is done in tests/default.rs) however, this seems to demote the test to the status of sample code (ie never actually run with cargo test) on account of this: https://users.rust-lang.org/t/feature-based-conditional-excludes-test-from-cargo-test-inventory/95924

…regardless of which combination of features are enabled
@luketpeterson
Copy link
Contributor Author

Seems the way I (and the tests/default.rs) file were doing conditional compilation was just broken. I fixed that, and added feature gates to all tests, so now cargo test should pass regardless of which combination of features are enabled.

Synchronizing 3 copies of README.md in the repo
@luketpeterson
Copy link
Contributor Author

Committed README updates, also synchronizing README content across sub-crates within the repo.

@bnjjj bnjjj merged commit 75b974a into bnjjj:master Jun 26, 2023
@bnjjj
Copy link
Owner

bnjjj commented Jun 26, 2023

Thanks a lot. Released on 0.12.0

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

Successfully merging this pull request may close these issues.

2 participants