Hi All, I'm particularly interested in the enhancements to the discovery.yml and the discovery process in general. I'd like offer our time and ideas if that's welcome! In our use of Meltano, we have separated the search / discovery of plugins from the plugin installation. In our usage, the discovery.yml is the plugin metadata definition (NB - not discovery), and the meltano.yml is a configuration option for the plugin in the project. We are currently generating a discovery yml for any plugin used in a project and using this to enable setting collection. meltano.yml is largely unused for us as the actual setting values are only known at runtime - e.g. its common to have many configurations of the same extractor (tap) in the same project. Imagine the following - "tap-spreadsheet-anywhere" extracting from 6 spreadsheets in the one project. I've put my thoughts into the epic as a comment with user stories. https://gitlab.com/groups/meltano/-/epics/128#note_734475476 Happy to move this discussion somewhere else if you prefer. Thanks!

Thanks for the comment on the epic, Aaron! Just to confirm, you’re adding the user stories b/c you’re generally supportive of this direction and want to add clarity to the development, correct? Just making sure I didn’t miss a big change/suggestion from what we basically have currently.

I posted a comment in reply and a reference to a related proposal: https://gitlab.com/meltano/meltano/-/issues/3031

@taylor yes, I do support the project stability direction. I felt adding the user stories helped add some clarity and led me to the conclusion one big discovery.yml has many limitations. In the issue comment, I'm proposing an approach more project centric like the lock file, but I felt the lock file didn't capture the need for settings definitions as well as versions to be in the project. There's also a related issue to version pinning when not using pip based artifacts that I avoided bringing into this!

@aaron_phethean great - thanks for the clariification!