💯 agreed, but no time right now.

This sounds a bit dangerous because cf-scripts already depends on conda-smithy for access to the Pydantic schema (and also other things?). Making this change would introduce a circular dependency.

Are there any drawbacks of the current solution?

We could make another repo or just download one self-contained python file that lives in regro/cf-scripts.

It's a separation of concern issue. conda-smithy should not be the place where BotConfig lives because it does not use it. The place where the botconfig is used is cf-scripts. Another issue is that making changes in the bot should not have to wait on a conda-smithy release.

Yeah I agree @isuruf. More generally, the validation being done is useful, but it embeds our APIs in concrete when we typically have made much more fluid changes in the ecosystem.

How about moving the entire schema to a different package? This keeps the schema definition together (holding complexity low - I am a bit terrified by the "self-contained python file"), while still allowing more rapid iterations because only the different package would need to be released (I know conda-smithy releases are quite tedious).

That would require co-ordinating the release of conda-smithy and the new package. The whole point is to make the bot config be independently developed from conda-smithy.

A direct download from the bot repo seems totally fine for this purpose. We can do it when we refresh the static schema on disk in smithy. If the download fails, we just keep the old schema.

In principle jsonschema allows us to refer to remote resources (even if discouraged). We could fetch the cf-scripts JSON schema from that repo and use the defintions in the conda-forge.yml schema.

I think that's the idea.