Would it be possible to expose ValueKind from value.rs to allow some introspection?

ie, change: pub use value::Value; in lib.rs to pub use value::{Value, ValueKind};

Hello! config is a key component in many of my projects and I'd like to contribute back some functionality/bug fixes. Looking at PRs and issues, there seems to have been little to no activity on the project for the past 10 months or so.

Should the project be considered unmaintained or is it just temporary? Not interested in pressuring you to work on it, just trying to understand if, instead of contributing PRs, it might make more sense to start a fork to evolve it.

When implementing config::ValueKind for a custom type, the error invalid type: unsigned integer 64 bit '128', expected an signed 64 bit or less integer for key 'inner.unsigned' is thrown if the custom type contains a unsigned integer. The following is a minimum example:

#[derive(Deserialize, Eq, PartialEq, Debug)]
struct Container<T> {
    inner: T,
}

#[derive(Deserialize, Eq, PartialEq, Debug)]
struct Unsigned {
    unsigned: u16,
}

impl Default for Unsigned {
    fn default() -> Self {
        Self { unsigned: 128 }
    }
}

impl From<Unsigned> for config::ValueKind {
    fn from(unsigned: Unsigned) -> Self {
        let mut properties = HashMap::default();
        properties.insert(
            "unsigned".to_string(),
            config::Value::from(unsigned.unsigned),
        );

        Self::Table(properties)
    }
}

assert_eq!(
    Container {
        inner: Unsigned::default()
    },
    config::Config::builder()
        .set_default("inner", Unsigned::default())
        .unwrap()
        .build()
        .unwrap()
        .try_deserialize::<Container<Unsigned>>()
        .unwrap()
);

We're trying to use config-rs using the latest rust nightly-1.49-0, and we're getting:

thread 'main' panicked at 'attempted to leave type `linked_hash_map::Node<std::string::String, value::Value>` uninitialized
, which is invalid', /home/tyler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/
mem/mod.rs:659:9

I see this is also failing on your travis build too:

https://travis-ci.org/github/mehcode/config-rs/jobs/734764347#L291

cc @Nutomic

Resolves #148

This pull request adds a new type of source - AsyncSource, that supports async fn. Also, it modifies the builder in order to handle it properly. Builder implementation based on this article.

There is no implementation of such a source inside the library since there are various runtimes to choose from as explained in the rustdocs in this pull request.

One minor change - the type of Result in regular Source has been changed from type synonym defined inside the library to std's Result since ... type synonym was not exported from the crate.

Json5 tests have been modified for Windows. There was some issue with line endings I was not able to resolve in error message tests. CI for this package runs on Linux, so test will run.

This can be particularly helpful for MY_SERVER_PORT=4334 cargo run

I know that serde's hints should do this because of the deserialize_* functions, but there are cases where it uses deserialize_any (for me this happened when refactoring to a nested struct in an enum). Maybe there's a better serde pattern for that/this?

In the spirit of making this library easier to get into and use, I'm thinking we should recommend a convention for configuration (that could, of course, be disabled with feature flags).

1 - ./config folder with ./config/default.toml and ./config/{env}.toml

config::merge(config::File::with_name("default").path("config"));
config::merge(config::File::with_name(env!("RUST_ENV")).path("config").required(false));
config::merge(config::Environment::new(""));

2 - ./Settings.toml / ./Settings.{env}.toml

config::merge(config::File::with_name("Settings"));
config::merge(config::File::with_name(&format!("Settings.{}", env!("RUST_ENV"))).required(false));
config::merge(config::Environment::new(""));

3 - ./Settings.toml with namespaces

config::merge(config::File::with_name("Settings").namespace(env!("RUST_ENV")).required(false));
config::merge(config::Environment::new(""));

An example of 3:

[development]
debug = true

[production]
debug = false

• This is using a unwritten feature of config::File to auto-detect the file type

The idea is that the equivalent of the above is done automatically. I'm partial to 3 but I'm open to other suggestions.

Environment variable names are converted to lower case internally. This is surprising undocumented behavior. We want to be able to override values from a configuration file with environment variables. It would be natural to use the same spelling (not counting the prefix), but this doesn't work if the configuration file keys are upper case. To make it work, the configuration file keys must be lower case.

config.toml

FOO="You can't override me!"
bar="You can override me just fine."

In the shell

APP_FOO="Why are you ignoring me?" APP_BAR="Yay! New bar." ./target/debug/app

I was using TOML for the config file and bash for the shell, if it matters.

I have been thinking about releasing a v0.12.0 a few times already, but I guess we should tackle it.

There is a milestone of a few things I wanted to have in the release, but given that we already have a lot of changes, I would be okay with moving them to the v0.13.0 release.

What do you think, especially @szarykott and @danieleades ? Lets discuss!

Also, I need to double-check whether I can make releases on crates.io ! :laughing:

This is a draft PR to show an idea of how could ConfigBuilder look like.

It does not bring a lot of new functionality. It just splits Config that was a mutable configuration combined with a builder into two separate structs. It brings certain benefits:

• Config is no longer refreshed when a new source is added
• More from the clean code perspective, it lifts concepts of "mutable" and "frozen" config to type level, thus mitigating runtime errors. It is a clean code issue, as Config could not be frozen before as it was a dead private API.

Immutability is considered good programming practice, but not everyone might like it. I'd like to hear the opinions of users of the library - do you mutate config often after application initial bootstrap, do you consider such a mutability a needed feature?

I do not intend to push it in its current form, it is just to showcase an idea. To consider it mergeable discussion has to take place regarding few subjects:

• is it the correct way to go
• should old ways be deprecated as it is done now or should they be removed

In the current state there is a lot of deprecation warnings, so please do not mind them now and focus on more high-level aspects of this PR.

I attach a graph of the intended workflow so that it is easier to see the big picture.

I'd like to write some conversions for my own structs from instances of Value, and std::convert::TryFrom / TryInto are good choices for this. However, the existence of a try_into method on the struct, unrelated to these traits, shadows the trait method.

Could the try_into method be renamed into try_deserialize or something of the sort?

Hi, in many situations when multiple sources of configurations are used - it's beneficial to have ability of Config metadata to tell which value came from which source and became effective/actual at the end of sources processing.

Implementation of this could add extra feature, for example "config-meta" and once used/enabled - later have method like "get_meta" or "dump_meta".

So if let say I have something like such for config construction out of 2 sources:

fn make_config() -> Config {
  let current_env = env::var("ENV").unwrap();
  Config::builder()
      .add_source(File::new("env/service", FileFormat::Yaml))
      .add_source(File::new(("env/service-".to_string() + &current_env).as_str(), FileFormat::Yaml))
      .build()
      .unwrap()
}

and let say one of my YAMLs has such:

debug: false

and another:

debug: true

then that new method "dump_meta" could print something like this:

debug: false <= taken from service.yml
debug: true <= taken as override from service-dev.yml and effective

As I'm yet new to Rust - this is just proposal at this point from my side, which I could try to implement one day if no volunteers.

I want to use this crate to parse a toml config file. This is part of my current code:

#[derive(Deserialize)]
pub struct ConfigRawFile {
	command: Option<String>,
	interval: Option<f64>,
	fg: Option<String>,
	bg: Option<String>,
	fg_cursor: Option<String>,
	bg_cursor: Option<String>,
	bg_selected: Option<String>,
	bold: Option<bool>,
	bold_cursor: Option<bool>,
	keybindings: Option<KeybindingsRaw>,
}

fn parse_toml(config_file: &str) -> Result<ConfigRawFile, config::ConfigError> {
	config::Config::builder()
		.add_source(config::File::with_name(config_file))
		.build()?
		.try_deserialize()
}

However, I want to give e.g. bg_cursor a different name that should be read from in the toml file. I would like the toml file to specify "bg+" (which I can't use as a variable name in rust due to the +), and then read that into bg_cursor. Is there an annotation I can use for this (similar to #[arg(long = "bg+", value_name = "COLOR")] in clap)? This would be very useful! Thanks!

Getting the following error when trying to get an environmental variable from config-rs:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: configuration property "DEV_SERVER_ADDRESS" not found', src/app/config.rs:14:27 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

use config::Config;
use lazy_static;

lazy_static! {
    #[derive(Debug)]
    pub static ref CONFIG: Config = Config::builder()
        .add_source(config::Environment::with_prefix("APP_NAME").separator("_"))
        .add_source(config::File::with_name("AppName"))
        .build()
        .unwrap();
}

pub fn get<'a, T: serde::Deserialize<'a>>(key: &str) -> T {
    CONFIG.get::<T>(&key).unwrap()
}

ENV variable:

export APP_NAME_DEV_SERVER_ADDRESS="testtt dev addr"

Trying to get the variable in main:

#[actix_web::main]
async fn main() -> result::Result<(), io::Error> {

    let dev_server_address: String = app::config::get("DEV_SERVER_ADDRESS");
    println!("DEV_SERVER_ADDRESS: {}", dev_server_address);
...

What am I doing wrong?

It could be an idea to have a best practice example of loading a configuration from a file, changing a value, and then saving it out in say a .toml format.

I'm working on feature control library and would like to take dependency on Value and path::Expression. Unfortunately, path::Expression is not public module. It is useful even outside the context of config-rs. Can you make it public in the next release?