Root-level 'user' property is a strange object

Take the following code:

package com.example

import java.nio.file.Paths
import pureconfig._
import pureconfig.generic.auto._

case class MyConf(user:String, password:String)

object MyConfLoad {
  def main(args:Array[String]):Unit = {
    val loadedConfig = loadConfigOrThrow[MyConf](Paths.get("conf/my-conf.conf"))
    println(loadedConfig.user)
  }
}

… and the following config file:

# conf/my-conf.conf
user = "foo"
password = "bar"

In 0.11.1 this causes:

Exception in thread "main" pureconfig.error.ConfigReaderException: Cannot convert configuration to a com.example.MyConf. Failures are:
  at 'user':
    - Expected type STRING. Found OBJECT instead.

	at pureconfig.package$.getResultOrThrow(package.scala:139)
	at pureconfig.package$.loadConfigOrThrow(package.scala:172)
	at com.example.MyConfLoad$.main(MyConf.scala:12)
	at com.example.MyConfLoad.main(MyConf.scala)

In earlier versions (e.g. 0.8.0) it causes:

{"country":"US","dir":"/Users/me/projects/myproj","home":"/Users/me","language":"en","name":"me","timezone":"America/New_York"}

Something odd is happening with the ‘user’ property. However, if I switch it to ‘username’ it works fine. Also, if you add it to a sub-object of the root object it works fine.

[leifwickland]

@deusaquilus,

You’re getting bitten by the default behavior of typesafe config, which is the library underlying pureconfig. You’ll notice in that documentation that the highest priority source for configuration is “system properties” which includes environment variables. Your shell almost certainly creates a USER env variable.

To work around that you can manually load only the files you care about. Doing that will be much easier in the next version of pureconfig. Currently it’s kind of a hassle. I’d be happy to help you through it if you need a hand.

TL;DR: It’s a feature, not a bug. 😉

[ruippeixotog]

Starting at v0.12.0 (released today) you should use ConfigSource objects to mix and match the files or resources you want to load 🙂 See the docs here!

Closing this as the behavior reported is expected according to Typesafe Config’s defaults.