Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
Provide a generic implementation for using YAML as a form of discovery alongside other discovery mechanisms.
Proposed resolution
Add a YAML Discovery decorator, so this can be used with other discovery mechanisms. For example, 'static' plugins can be declared in yaml but custom implementations can still be declared via annotations.
Remaining tasks
Commit the patch
User interface changes
None
API changes
Just an addition of this decorator.
Related Issues
#2065571: Add YAML Plugin discovery
Original report by @damiankloip
Comment | File | Size | Author |
---|---|---|---|
#11 | yaml-2076681-11.patch | 4.82 KB | pwolanin |
#11 | 2076681-10-11.increment.txt | 762 bytes | pwolanin |
#10 | yaml-2076681-10.patch | 4.83 KB | dawehner |
#10 | interdiff.txt | 615 bytes | dawehner |
#1 | 2076681-1.patch | 4.67 KB | damiankloip |
Comments
Comment #1
damiankloip CreditAttribution: damiankloip commentedSo it looks like the idea from to use a decorator #2050919: Replace local task plugin discovery with YamlDiscovery that got unnecessarily removed in #2065571: Add YAML Plugin discovery has come back round full circle :)
Here is a unit test for the decorator.
Comment #2
dawehnerA foreach nearly all times shout to a data provider, as here?
Comment #3
dawehnerI got convinced
Comment #4
damiankloip CreditAttribution: damiankloip commented:), the general summary was that using a data provider here would just be for the expected keys, and that would make the test way more confusing to read.
Comment #5
dawehnerI disagree damian, this was RTBC.
Comment #6
pwolanin CreditAttribution: pwolanin commentedi'm not sure about this now.
If the overall goal is to encourage only trivial variants to be discovered this way, I think this should unset at least 'class' and 'derivatives' key from anything that's discovered.
In the case of the local action/task use case, that would mean you'd need to directly annotate any custom class - which I think is a good idea.
Comment #7
msonnabaum CreditAttribution: msonnabaum commented#6 sounds insane to me. If implementations need to customize this generic behavior, they can.
Comment #8
pwolanin CreditAttribution: pwolanin commentedGiven a lack of enforcing a class or validating keys, I'm not sure this minimal/generic implementation is useful.
I don't care if it goes in or not, but I don't think it's something you'd want to use alone in most cases.
Comment #9
damiankloip CreditAttribution: damiankloip commentedIt makes alot of sense to have a generic base implementation that works, and is unit tested. If you want to then extend that, you can.
Comment #10
dawehnerThere we go.
Comment #11
pwolanin CreditAttribution: pwolanin commentedBased on long-winded discussion in IRC: This class and the underlying YAML plugin discovery are very generic and in most cases need to be extended to provide better checks on the classes or data found in the YAML files.
Revising dawehner's suggested code comment since he's busy on another issue and setting back to rtbc.
Comment #12
damiankloip CreditAttribution: damiankloip commentedYou make it sounds like everybody agreed on that, really it was just you... I said this was a slightly pointless idea, as it sounds a bit presumptuous to me.
Whatever though, looks fine. Things like this sap any drive I have to work on core.
Comment #13
alexpottCommitted 36a898e and pushed to 8.x. Thanks!
Comment #14.0
(not verified) CreditAttribution: commentedUpdated issue summary.