Oops, you're right, thanks, I was running the buil...

# dagger

[dave08]

Oops, you're right, thanks, I was running the build with intellij and it didn't give me dagger error that I was missing a @Provides, only when I ran in terminal, I saw it, now everything works! Your 'did you see `kaptGenerateStubs`' question made me look there ... 😊

[gildor]

I see compile error in Idea with good error message that explains problem with lack of @Provides

[gildor]

Do you have “Delegate IDE build/run actions to gradle” option enabled?

[dave08]

Oh, maybe not, because I need to pass some local environment vars for service configuration... could that be done in gradle?

[gildor]

Yes, of course. Gradle can read environment variables. Also you can use gradle properties for that, to specify some config variables

[gildor]

Also Idea allow you to set environment variables

[dave08]

With “Delegate IDE build/run actions to gradle” option enabled?

[gildor]

Yes

[gildor]

I don’t know exactly your case so cannot recommend more specific solution. Usually with gradle I don’t use environment variables locally (but use on CI), but use property files

[dave08]

Docker recommends all configs should be through env. vars, also in Docker Swarm services are harder to configure per environment w/ config files... we also have Jenkins that will need to run the tests...

How do you manage your config loading, straight in the dagger module while instantiating deps or through a common config class?

[gildor]

Yeah, if you run using Docker no problem, just pass them as environment variables.
I’m talking about local development

[gildor]

Don’t exactly understand you question about config loading.
Usually I try to have as less as possible code in dagger module, in 99% only constructor/factory invocation.
So for config I would instantiate some class that implements this config and return as dependency
But maybe I understand you question incorrectly

[gildor]

Also it’s pretty common case in our app when we provide particular config property directly without exposing full config for clients. Something like:

@Provides
@Named("some_config_property")
fun provideSomeProperty(config: MyConfigInterface): String {
    return config.someProperty()
}

and use it on client side:

class SomeClientClass @Inject constructor(@Named("some_config_property") someProperty: String)

[dave08]

For example, instantiating a db client needs multiple config vars, so currently I have a provideDbClient that has lots of `System.getenv("...")`s in the constructor, also I run a login function in an xmlrpc dep. in provide XmlrpcClient, but I was wondering if that should also be abstracted in factory classes? Or maybe that's part of the point of DI is to take care of providing objects that are ready for use...

Also, I'm still not clear on when to use inject on a constructor, if I still have to write a provider function for it...

[gildor]

My opinion that you always should avoid to call System.getenv in a class constructor or anywhere in your business logic. You can do that in DI (module) or in some special config implementation, something like MyConfigEvnVarsImplementation

[gildor]

I’m pretty sure, DI should provide ready to use object if you need config class with multiple values or just single config value

[gildor]

when to use inject on a constructor

There are different opinions about that.
Imo @Inject constructor is really useful, reduces boilerplate. Also you can use it even in case of polymorphic dependency with @Binds annotation on module method. So our internal guideline: use @Inject constructor as much is possible and use provide method when it’s impossible to do or you want to override some dependency.
But some people has opposite guidelines, to use only provide methods, but I’m not sure that “keep everything in one place” is good reason.

[gildor]

I have a provideDbClient that has lots of System.getenv("...")

For example in your case I would use constructor inject for you DbClien (probably with @Bind if client is polymorphic) and to provide all client config properties use some class with configuration properties:

class XmlrpcClient @Inject constructor(config: DbConfig) // Probably use named config instead

class SystemEnvDbConfig @Inject constructor() // And just init instance using System.getenv in constructor

interface MyDbModule {
    @Binds fun provideDbClient(impl: XmlrpcClient): DbClient
    @Binds fun provideDbConfig(impl: SystemEnvDbConfig): DbConfig
}

[gildor]

So that’s all. You can use XmlrpcClient or DbClient as dependency of any other class, Dagger will build graph for you

[gildor]

Of course it’s just one of solutions, depends on how many abstraction level do you need and how flexibly graph do you need. You can avoid DbConfig abstraction and use your current approach, where you just use @Provides method that constructs DbClient using System.getenv