load config from Source or similar to increase testability

Right now the loadConfig methods provided by pureconfig are oriented around java.nio.Paths when a non-default location is required. However for those wishing to unit test their configuration code without having said tests go to the filesystem, this presents a problem as Path is not readily mocked. To this end I would propose adding another variant of loadConfig that takes something less tightly bound to the filesystem itself. Options include fs2 streams which would be nice however I suspect pureconfig does not want to introduce a dependency on fs2? Otherwise, scala.io.Source seems like a good candidate.

If this idea is deemed useful happy to provide a PR.

[ruippeixotog]

I’m ok with adding an overloaded loadConfig(source: Source) to our API, if the other authors agree. The most elegant bridge wouldn’t be through a String IMO, but from a Java Reader (there’s Source#reader() and ConfigFactory.fromReader).

Please bear in mind that, while there’s an open issue to make PureConfig independent from the backend API, that’s not at all the case right now. Typesafe Config is not a simple transitive dependency: our API intentionally does not abstract over it and com.typesafe.config.Config is not purely an intermediary, but our core model of a config. On the upcoming version there will be a greater distance from concrete backends with the implementation of ConfigCursors, but if you are using the current version (0.8.0) and you need to add support for a custom type, you’ll still have to deal with instances of ConfigValue. As such, I wouldn’t personally feel like I was breaking some abstraction layer by creating a Config manually.

[keirlawson]

Ok, will close issue.