search

conda-forge / conda-smithy

The tool for managing conda-forge feedstocks.
https://conda-forge.org/
BSD 3-Clause "New" or "Revised" License
146 stars 170 forks source link

Move BotConfig to regro/cf-scripts and use it in conda-smithy #1893

Open isuruf opened 4 months ago

isuruf commented 4 months ago

I think it makes sense for the BotConfig to live in regro/cf-scripts

cc @beckermr, @ytausch, @xhochy, @jaimergp

beckermr commented 4 months ago

💯 agreed, but no time right now.

ytausch commented 4 months ago

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?

isuruf commented 4 months ago

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.

beckermr commented 4 months ago

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.

ytausch commented 4 months ago

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

isuruf commented 4 months ago

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.

beckermr commented 4 months ago

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.

jaimergp commented 2 months ago

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.

beckermr commented 2 months ago

I think that's the idea.