Does anyone have a solution for a use-case as described here, i.e. to override a single property within a list from the command line (not environment)?

Hi - is there a

ConfigLoaderBuilder

recipe that mimics the opinionated default loader behaviour of TypeSafe/Lightbend Config, including fallbacks and the various optional property overrides? https://github.com/lightbend/config/blob/main/README.md#standard-behavior

Also, does the builder cache the built configuration environment variables used somewhere? I've written some tests injecting environment vars, and they pass when run individually, but there are failures when run as a suite. If so, is there an approach (apart from the

ReloadableConfig

) that forces expiry of cached values?

I'm loving the

withReport

feature and its related decorators like the HashObfuscator...I don't see it documented yet though, so wondering if it's already documented somewhere, or if you're intentionally not documenting it yet for any reason? If not, lemmeno and I'd be willing to submit a PR for its documentation.

We should add the documentation yeah, I added that feature as we use it internally when deploying our microservices, and it's been in use for about a year, so it's fully stable.

Say I have:

http-clients:
  client-1:
    url: ...

and I'd like to map it to:

data class Configs(val httpClients: List<HttpClientConfig>)

data class HttpClientConfig(val name: String, val url: String) // Is there some kind of annotation to pull the name 'client-1' out from the map key and use it as name here and have the result as a list? Or even:

data class Configs(val httpClients: Map<String, HttpClientConfig>) // And still not having to specify name in client-1 configs since it can be pulled in from the key...?

you would need to do:

http-clients:
  - name: client-1
    url: ....

Say I have a configuration in yaml

s3Configs:
  accessKey: ...

would the env var S3CONFIGS__ACCESSKEY work @sam?

(C in

s3 C onfigs

in capital and

access K ey

is too)

I don't think so no, it needs to match case or your var be all lowercase

It would have been nice to have control over cohort with Hoplite... like in Micronaut, where you can change log levels (or metrics, etc...) using config files or env vars etc... I guess I could always make a data class for all it's options and copy-paste it in all projects, but I think it's a common use-case that could have a simple module that could be re-used...

Is there any chance https://github.com/sksamuel/hoplite/issues/386 would see any love in the near future? I would like to transition to hoplite from my forked version of cfg4k (https://github.com/rocketraman/cfg4k), but that issue is a blocker.

Trying to understand the interaction between

ConfigLoaderBuilder.addResourceSource

and the

inputs: List<ConfigSource>

parameter of

loadConfigOrThrow

. Why can we define sources in both places, and what happens if we do?

Has anyone else had any luck using the Arrow

NonEmptyListDecoder

with a value class? It seems to work fine with a normal

List

field or with

Nel<String>

(although the error for an empty list isn't particularly helpful: "Required type class arrow.core.NonEmptyList could not be decoded from a List")

It would appear hoplite only lets one map to data classes out of the box and not plain classes. Is that right? I come across frameworks that use

class

to hold config values. It would be nice just to use that class for loading. Did I overlook something (a decoder)? If not, do i need to implement a decoder?

data classes only yes

You could add your own data class and map after the config is loaded

fun config() = ConfigLoader.builder()
    .addEnvironmentSource()
    .addPreprocessor(
        VaultSecretPreprocessor(
            {
                VaultTemplate(
                    VaultEndpoint.create("MY_HOST", MY_PORT),
                    TokenAuthentication("MY_TOKEN")
                )
            }
        )
    )
    .addResourceSource("/application.conf")
    .withExplicitSealedTypes()
    .build()
    .loadConfigOrThrow<Config>()

Are there any elegant way of resolving the env variables here or is the easiest to just fall back to

System.getEnv(...)

?

Is there any chance this could be added (I hope I did it right...)?

class IntRangeDecoder() : Decoder<IntRange> {
    override fun supports(type: KType): Boolean = type.classifier == IntRange::class

    override fun decode(node: Node, type: KType, context: DecoderContext): ConfigResult<IntRange> = when(node) {
        is StringNode -> runCatching {
            node.value.split("..").let { IntRange(it[0].toInt(), it[1].toInt()) }
        }.toValidated { ConfigFailure.DecodeError(node, type) }

        else -> ConfigFailure.DecodeError(node, type).invalid()
    }
}

Yeah just pr it :)

👋 @sam I have a ktor service that runs (for now) in ElasticBeanstalk. It's been on hoplite 2.7.5 and I updated to 2.9.0 today. all fine. Then I tried to move from

hoplite-aws

to

hoplite-aws-kotlin

and ran into issues with the credential provider..only in EB.

aws.smithy.kotlin.runtime.identity.IdentityProviderException: No identity could be resolved from the chain: CredentialsProviderChain -> SystemPropertyCredentialsProvider -> EnvironmentCredentialsProvider -> ProfileCredentialsProvider -> StsWebIdentityProvider -> EcsCredentialsProvider -> ImdsCredentialsProvider

I switched over to

hoplite-aws2

and all is fine. But I can't figure out what's going on with the kotlin version. Nothing else changed..not my config code or anything about the EB environment. Have you run into this before? We're not planning to stay on EB and I suspect that there's something about accessing roles there that either the hoplite library, or the underlying aws library doesn't like.

Hi guys, Quick q: are yaml merge keys supported? Glimpsing over the Yaml parser I see references to anchors/aliases at the yaml parser, which are very related features, but nothing on merge keys. I know merge keys are not part of the 1.2 spec, only 1.1, but they are quite handy 😄 I’ll leave some details in a just for the sake of completion 🧵 Thank you!

is https://github.com/sksamuel/hoplite/pull/477 something that can make it in to a patch release?

I can back port to 2.8.x sure

@sam Could this also be a candidate for backport ? https://github.com/sksamuel/hoplite/pull/476

@sam Do you think it is that possible to do a new release? (a MR has been merged for a while and still not released) That would really help 🙏

Can anyone explain to me what the (undocumented)

prefix

parameter of the

loadConfig()

functions does? When loading e.g. from a YAML file, does it allow to limited loading to a nested key of that name?

Apparently

loadConfig()

fails if there is nothing to load from any configured property source. I'd like to fall back to some default configuration on that kind of "failure". However, I still want to capture "real" failures, like syntax errors in configuration files. What's the correct way to distinguish "no config available" from "config broken" in Hoplite?

Looked through issues and pull requests, but doesn't look like anyone has requested a 1password preprocessor.... thoughts or objections to me adding one @sam?

Alô! Exception in thread "main" java.util.ServiceConfigurationError: com.sksamuel.hoplite.decoder.Decoder: Provider com.sksamuel.hoplite.decoder.LocaleDecoder not found I'm getting this exception when trying to package an UberJar using hoplite. It's a niche Jetpack Compose Desktop app. How to start understanding this error? I think it's because Hoplite depends on java meta but compose is not packing them