Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 31 15:23
    ashabhasa starred pureconfig/pureconfig
  • Jan 30 20:03

    ruippeixotog on master

    Update cats-effect, fs2 and htt… Merge pull request #448 from ba… (compare)

  • Jan 30 20:03
    ruippeixotog closed #448
  • Jan 30 08:05
    Mao1990 starred pureconfig/pureconfig
  • Jan 29 13:08
    bardurdam opened #448
  • Jan 29 10:20
    PatrykRudnicki starred pureconfig/pureconfig
  • Jan 28 18:52

    ruippeixotog on master

    Create a FluentConfigCursor Merge branch 'master' into flue… Fix yaml module on Scala 2.11 and 3 more (compare)

  • Jan 28 18:52
    ruippeixotog closed #443
  • Jan 28 18:02
    ruippeixotog synchronize #443
  • Jan 28 18:02

    ruippeixotog on fluent-cursor

    Create scalaz module for pureco… Merge branch 'master' into scal… Update module with latest Confi… and 19 more (compare)

  • Jan 27 14:09
    esumitra starred pureconfig/pureconfig
  • Jan 27 01:55

    ruippeixotog on master

    Create scalaz module for pureco… Merge branch 'master' into scal… Update module with latest Confi… and 6 more (compare)

  • Jan 27 01:55
    ruippeixotog closed #444
  • Jan 27 01:19
    ruippeixotog synchronize #444
  • Jan 27 01:19

    ruippeixotog on master

    Add cron4s module - add cron4s… Merge pull request #446 from ba… (compare)

  • Jan 27 01:19
    ruippeixotog closed #446
  • Jan 26 22:51
    ChernikovP synchronize #444
  • Jan 26 22:37
    bardurdam synchronize #446
  • Jan 26 22:36
    bardurdam commented #446
  • Jan 26 22:31
    bardurdam synchronize #446
Chetan Mehrotra
@chetanmeh
See here for a template is used to enumerate the field names itself in spray-json
Joao Azevedo
@jcazevedo
@chetanmeh: In your example, isn't the RuntimesRegistryCredentials type used in other configuration types? If so, it's preferable to define the implicit ConfigReader[RuntimesRegistryCredentials] in the companion object of RuntimesRegistryCredentials so that it is in the implicit scope of that type.
Regarding the forProductN, spray-json uses reflection to extract the field names, and we would like to avoid using reflection in PureConfig. Nonetheless, deriveReader[Color] should have the behaviour you expect from spray-json's jsonFormatX.
Chetan Mehrotra
@chetanmeh

If so, it's preferable to define the implicit ConfigReader[RuntimesRegistryCredentials] in the companion object of RuntimesRegistryCredentials so that it is in the implicit scope of that type

yeah makes sense and we do similar things for spray-json

spray-json uses reflection to extract the field names, and we would like to avoid using reflection in PureConfig

In there readme it says that

Type-class based (de)serialization of custom objects (no reflection, no intrusion)

So I assumed its not using any reflection at runtime. Is that false understanding?

Chetan Mehrotra
@chetanmeh
Joao Azevedo
@jcazevedo
The "no reflection" is probably a mention to the type class approach in general.
Chetan Mehrotra
@chetanmeh
But that would be one time cost only to initialize the format
Post that there should be no "reflection tax"
Joao Azevedo
@jcazevedo
That's true.
Chetan Mehrotra
@chetanmeh
Would having similar support in pureconfig be useful? Problem with current manual approach is its very manual :)
Its fine to have code written to create implicits explicitly in companion objects
but then enumerating each field name of case class requires quite a bit of effort
Joao Azevedo
@jcazevedo
And you'd like to avoid using the semi-automatic approach?
Chetan Mehrotra
@chetanmeh
yeah as in our case config classes are not reused much. So not sure if semi automatic would help there much.
As there would not be much reuse post caching and a new class would retrigger the discovery
Joao Azevedo
@jcazevedo
As there would not be much reuse post caching and a new class would retrigger the discovery
What do you mean?
Chetan Mehrotra
@chetanmeh
I meant if we have lots of unique case class config like MesosConfig, RuntimesRegistryConfig (say 80-100)
Then even if I cache the implicit resolution of MesosConfig it would not help resolution of reader for RuntimesRegistryConfig
(if I understood the intention of semi auto variant correctly)
Joao Azevedo
@jcazevedo
I'm not sure I understood. If you have MesosConfig(..., r: RuntimesRegistryConfig) and OtherConfig(..., r: RuntimesRegistryConfig) the idea is that you derive a reader for RuntimesRegistryConfig only once, and reuse it in the derivations of MesosConfig and OtherConfig.
Chetan Mehrotra
@chetanmeh
That would work. But in our case there is not much reuse of config types
each config is more or less unique with no reference to any other config
Joao Azevedo
@jcazevedo
It would still help in relation to the fully automatic approach because in full auto you are deriving readers every time you need them (usually at the loadConfig* entrypoints).
Chetan Mehrotra
@chetanmeh
Ack. But in our case its mostly unique config loaded at one place. So each part of application logic would invent a new config structure and load it upon init
Hence my doubts on semi auto variant helping much in reducing compile time
Chetan Mehrotra
@chetanmeh
Would having a semi manual approach along the line of approach taken in spray-json would be useful? If yes I can open an issue and see if I can come up with a PR for the same
Joao Azevedo
@jcazevedo
The readers derived via pureconfig-generic by default (among other things) transform the names of fields in case classes to config files (from camelCase to kebab-case). Would that approach do the same?
Chetan Mehrotra
@chetanmeh
should be possible. We can make the semi manual approach similar to generic approach post resolution of field names
Joao Azevedo
@jcazevedo
I'm inclined to prefer the manual approach (at least in the core module) as is. For one, I wouldn't like to introduce runtime reflection into PureConfig. Also, I think that not specifying everything in the manual approach would create some expectations that the API would have similar configuration points as in pureconfig-generic, and I'd like to keep ProductHints in pureconfig-generic.
That being said, others may disagree, so I think you should open an issue to gather more feedback.
Chetan Mehrotra
@chetanmeh
Okie. So if we need to have a semi manual approach then best would be to have a completely new sub module which also support some construct like product hint
makes sense
Chetan Mehrotra
@chetanmeh
Created pureconfig/pureconfig#485 to track this
Chetan Mehrotra
@chetanmeh
Supporting default values would be tricky :|
Rui Gonçalves
@ruippeixotog

I'm inclined to prefer the manual approach (at least in the core module) as is. For one, I wouldn't like to introduce runtime reflection into PureConfig. Also, I think that not specifying everything in the manual approach would create some expectations that the API would have similar configuration points as in pureconfig-generic, and I'd like to keep ProductHints in pureconfig-generic.

I echo this. One of the motivations of extracting shapeless-style derivation from core was to allow for modules with alternative ways to derive classes (one of the alternatives mentioned was to use Magnolia). Using spray-json style reflection could be another alternative :)

Chetan Mehrotra
@chetanmeh
@ruippeixotog any examples of using magnolia with pure config.
Rui Gonçalves
@ruippeixotog
https://github.com/pureconfig/pureconfig/issues/396#issuecomment-411344203 has a stub of how a Magnolia integration would be. Creating a Magnolia module is on my nice to have list, I may try building one when I find the time
Peter Goransson
@pgoranss
Hi guys, is there a way to use pureconfig from Java? I've gotten as far as this but stuck on the implicit Derivation (noted with "..."); pureconfig.package$.MODULE$.loadConfig(config, ... );
Rui Gonçalves
@ruippeixotog
The short answer is no, there isn't. Most features provided by PureConfig are based on the Scala compiler's ability to find and derive implicit instances - with Java you are much better off using typesafe config directly (https://github.com/lightbend/config)
Peter Goransson
@pgoranss
That is what I thought too -Thanks for confirming!
Igal Benardete
@igalbenardete
Is there a way to tell PureConfig to parse reconnect.backoff.max.ms ? Separated with .'s
Creating this as a Case Class structure is a bit cumbersome for a single parameter
Chetan Mehrotra
@chetanmeh
You can use something like loadConfigOrThrow[Int]("reconnect.backoff.max.ms")
lmeyer
@LeonardMeyer

Hi. I'm using an old version of pureconfig (0.9.1) that I can't upgrade right now, so I can't use deriveEnumerationReader. I have a ADT of case objectlike so

sealed abstract class FormatSaveMode(val value: String)
object FormatSaveMode {
  case object Append extends FormatSaveMode("Append")
  case object Overwrite extends FormatSaveMode("Overwrite")
  case object ErrorIfExists extends FormatSaveMode("ErrorIfExists")
  case object Ignore extends FormatSaveMode("Ignore")
}

I expect my conf to provide a string for my json mode field (which deserializes to FormatSaveMode) with the exact case object name. So I did this :

implicit val test: FieldCoproductHint[FormatSaveMode] = new FieldCoproductHint[FormatSaveMode]("mode") {
      override def fieldValue(name: String): String = name
    }

But I get Expected type OBJECT. Found STRING instead.. So I must be doing something wrong, I don't want to provide an object here, this looks weird :

      mode: {
        mode: "Overwrite"
      }

It should be

        mode: "Overwrite"
lmeyer
@LeonardMeyer
I ended up implementing my own ConfigReader ¯\(ツ)
Joao Azevedo
@jcazevedo
@LeonardMeyer: FieldCoproductHint assumes that FormatSaveMode will be serialized as a ConfigObject.
You should use EnumCoproductHint instead.
lmeyer
@LeonardMeyer
Thanks, just what I needed