INHERIT would be close, though it leaves putting the parent file in place as an exercise for the user. Maintaining synchronisation of that across a lot of repos seems hard.

That's where the idea for a plugin came in. We could put the file an internal store (S3, intranet, git repo, ...) and have a plugin fetch it on build.

I like the idea of an on_pre_config hook. Although it would create a chicken-and-egg challenge of activating plugins enabled by the patched in config. It would need a two phase configuration load:

1. minimally discover plugins and checks for any on_pre_config hooks.
2. re-loaded with on_pre_config given chance to patch in changes.

Oh of course, the chicken-and-egg problem. How did that slip my mind

I guess one way around it might be to have a different form of plugin for this explicit task. If INHERIT were modified to accept a URL as well as a path, then the scheme in the url could be used to select which plugin to download from.

Eg:

• URL https://example.com/ might have one plugin based on the requests library
• URL s3://example-bucket/ might have another plugin to based on AWS's boto3 library

This wouldn't necessarily need any configuration, the necessary information would be right there in the URL.