feat: use an external json schema for botconfig

[isuruf]

As it says above...

bot schema was moved over here: regro/cf-scripts#3789

cc @ytausch @beckermr

closes #1893

[beckermr]

This is great. I'm fine producing the schema right in this repo and not having to use a gist. I'm guessing we'll have to merge once before that works?

Edit: I thought this was cf-scripts. Now this PR makes more sense to me. 🤦‍♂️

[isuruf]

We'll move the Pydantic model to regro/cf-scripts and dump the schema to that repo too. Then we can use the URL for that file here.

[ytausch]

Some thoughts about this:

• Do we really need Url and orjson here? I think it should be enough to reference the other schema as a string, removing the additional serialization overhead.
• I suggest not to include the other schema as JSON schema but rather to properly import it as a Pydantic model. Otherwise, it will not be possible to use the Pydantic model to access all fields, as explained here. I don't like seeing Pydantic to be downgraded to a JSON schema generation engine, as it's much more powerful if used correctly.

[beckermr]

pre-commit.ci autofix

[beckermr]

requires regro/cf-scripts#3789 to pass

[ytausch]

So, do I understand correctly that you decided to no longer support validating conda-forge.yml with pydantic?

[beckermr]

No we did not. We moved the serialized json schema and pydantic model to the bot code base.

The linter uses the json.

However, I'd accept a PR that adds an optional, non-default feature that imports the bot's model and makes a pydantic model at the python level that combines the smithy+bot ones. People can then import that model via python to do validation if they like.

The approach here isn't exclusive, but rather to have optional features for those who want them.

We cannot use the pydantic python code by default since it would create a circular dependency between the bots code base and smithy.

[ytausch]

However, I'd accept a PR that adds an optional, non-default feature that imports the bot's model and makes a pydantic model at the python level that combines the smithy+bot ones. People can then import that model via python to do validation if they like.

Unfortunately, dynamically generated pydantic models do not allow static type checking, which is a large part of the benefit I see in pydantic. Also, I feel it's problematic that we'd then have two different models describing the same thing.

We cannot use the pydantic python code by default since it would create a circular dependency between the bots code base and smithy.

We could avoid this by moving only the bot's pydantic model to a separate conda package. Both conda-smithy and the bot could depend on that package. WDYT about that?

[beckermr]

I'm against extra packages here for the same reasons as discussed for smithy.

It sounds like we can support some of the functionality but not all of it.

As I understand it, this model is mostly used to check yaml/json files, not python code.

So I think we've reached a decent compromise.

[isuruf]

It's been almost a year and no one is using the pydantic model AFAIK (other than dumping the json schema and validating through that)

[ytausch]

It's been almost a year and no one is using the pydantic model AFAIK (other than dumping the json schema and validating through that)

cf-scripts uses it here: https://github.com/regro/cf-scripts/blob/main/conda_forge_tick/models/node_attributes.py#L4

[beckermr]

Right and the model is now in cf-scripts so this will still work fine.