Move BotConfig to regro/cf-scripts and use it in conda-smithy about conda-smithy HOT 9 OPEN

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.

from conda-smithy.

💯 agreed, but no time right now.

from conda-smithy.

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?

from conda-smithy.

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.

from conda-smithy.

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.

from conda-smithy.

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).

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.

from conda-smithy.

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.

from conda-smithy.

I think that's the idea.

from conda-smithy.