# Can I use dry-auto\_inject in a gem and provide sane defaults

**URL:** https://discourse.dry-rb.org/t/can-i-use-dry-auto-inject-in-a-gem-and-provide-sane-defaults/201
**Category:** Uncategorized
**Created:** [January 23, 2017, 3:55pm UTC](https://discourse.dry-rb.org/t/can-i-use-dry-auto-inject-in-a-gem-and-provide-sane-defaults/201 "2017-01-23T15:55:25Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![billdueber](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.dry-rb.org/billdueber/32/79_2.png) [@billdueber](https://discourse.dry-rb.org/u/billdueber)
#### Post date: [January 23, 2017, 3:55pm UTC](https://discourse.dry-rb.org/t/can-i-use-dry-auto-inject-in-a-gem-and-provide-sane-defaults/201/1 "2017-01-23T15:55:25Z")

</div>

I’m writing a simple little search tree implementation. I provide bare-bones implementations of, say, how to deal with logical-AND, but I’d like knowledgable users to be able to override it.

SO…is there a way to set up default values for DI? I want the gem to be useful out-of-the-box, but also configurable if that’s your thing.

Ideally, a call to `MyClass.new` would work without any setup by the end-user at all.

My guess is either this is easy and I just can’t see it, or this isn’t a good way to do it and I don’t understand why.

---

<div class="post-metadata">

### Author: ![timriley](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.dry-rb.org/timriley/32/25_2.png) [@timriley](https://discourse.dry-rb.org/u/timriley)
#### Post date: [January 24, 2017, 3:38am UTC](https://discourse.dry-rb.org/t/can-i-use-dry-auto-inject-in-a-gem-and-provide-sane-defaults/201/2 "2017-01-24T03:38:17Z")

</div>

I think the best approach here would be to make your class _compatible_ with dry-auto\_inject, but not actually _use_ it.

So this means that your dependencies should be passed through the initializer, which is where you can also provide your defaults.

Then, if a user came along and wanted to use your classes with dry-auto\_inject, they could just include the mixin and it’d override defaults with the objects that it resolves from the container.
