New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate :include-refsets? in favor of :include-reflikes? #77
Comments
Also, (def config
{:some/handler 1
:some/other 2
:jetty/server (ig/refset :handler)})
(def system (ig/init [:jetty/server]))
;; => init ... build ... dependent-keys ... find-keys
;; => just :jetty/server ends up in the map |
Yes, that looks like a mistake. Let me think of the best way to handle this... perhaps via a |
No, that part is deliberate. If you have a configuration: {::a (ig/ref ::b), ::b 1} Then if you want to initiate {::a (ig/refset ::b), ::b 1} Because a refset can be empty, it's perfectly valid to initiate From a practical perspective, this allows you to initiate an explicit subset of a refset. |
This is a larger problem than it seems at first consideration. How can we tell whether a reflike behaves like a ref or a refset, and would adding more to the |
I guess there are 2 possible behaviors: lazy/minimal or greedy/maximal. Note, the (current) lazy/minimal one makes duct core's default |
The minimal strategy allows you to exclude keys from a refset, whereas a maximal strategy does not. With a maximal strategy you'd need to either lose functionality, or change how the keys are specified. Now it's true that in that particular case, the Duct default isn't a good one. But that's a very specific use case, and I think if you're going to do something unusual, overriding the default to something like Plus the way Duct is currently written, profiles and modules rely on the minimal strategy in order to define ordering. With a refset you can effectively say "if this key exists, ensure you come after it". |
I think we need a little time to ensure that reflikes work consistently, so what I'll do is to create a new However, I will rename the I'm thinking that we may want to have two additional protocol functions on reflike: |
Whether we call the option
Or possibly:
|
Sorry, I deleted my prior comment because it was bonkers, before you replied. The case I'm making now is for |
My thoughts come and go; to go back at my earlier (deleted) point (not all bonkers), better stated: In the great scheme of things a reflike can:
In light of this, optional/mandatory is a complication; whether this is a distinction that's needed, we have yet to have a concrete case. So rename to |
Let me know on which variant you're sold and I'll sketch a PR. |
I don't think we need that. It's more straightforward to just be explicit about the keys you want. Automatically including dependencies was only ever intended to pull in mandatory dependencies; i.e. it automatically includes the minimal set of keys that conform to what the user requires.
I don't think that's a good idea. Remember, anything we implement is going to be set in stone. We cannot remove options or behavior after Integrant hits 1.0, which ideally I'd like to do sometime this year. This also sets up special, hardcoded behavior for refs over other RefLikes. Again, this doesn't strike me as good design; ideally I'd like RefLikes to be consistent in how they behave. |
I arrived here wanting a way for
Say, handlers are in the hundreds or more, and added somewhat dynamically by a mechanism. Not quite straightforward, nor do I like it. It's ergonomic in EDN to declare deps as I'll leave this alone for now, but likely come back to it later. This is the main reason for this ticket.
Ok, continuing with the "optional/mandatory" variant, I'll try to have a PR soon; sketch:
(defprotocol RefLike
(ref-key [r] "Return the key of the reference.")
(ref-mandatory-keys r config "Returns the mandatory keys from `config`.")
(ref-all-keys r config "Returns the mandatory and optional keys from `config`.")
(ref-resolve [r config resolvef] "Return the resolved value."))
|
It doesn't matter how many handlers there are, as long as their keys share an ancestor. So for instance you might write: (ig/init config [:duct/daemon :my/handler)]) If you're using Alternatively, you could create a custom RefLike where all of the keys are mandatory.
Unless I've missed something, I don't think the |
I've added a |
These methods allow a RefLike implementation to determine which dependencies are optional for a reflike, and which dependencies are mandatory. Also renames `include-refsets?` to `optional-deps?`. Resolves: weavejester#77 See also: weavejester#63, weavejester#68
These methods allow a RefLike implementation to determine which dependencies are optional for a reflike, and which dependencies are mandatory. Also renames `include-refsets?` to `optional-deps?`. Resolves: weavejester#77 See also: weavejester#63, weavejester#68
These methods allow a RefLike implementation to determine which dependencies are optional for a reflike, and which dependencies are mandatory. Resolves: weavejester#77 See also: weavejester#63, weavejester#68
These methods allow for custom RefLike implementations with different dependency resolution logic. Fixes weavejester#77.
Let's release reflike. |
Naming of this config option is a bit misleading, it's called
:include-refsets?
but what it actually does is:include-reflikes?
, and it's misleading particularly post #68The text was updated successfully, but these errors were encountered: