I'm thinking about the priority. It would be nice to have individual packages that provide their own schemas to override "stores" that provide lots of schemas. For example, you might want to install schema-store + a specific version of cibuildwheel and get that version of cibuildwheel's schema, not the store version. The main reason for multi schemas to prioritize is they support extra schemas, but the downside is that all current packages that provide one schema are probably would like to override "stores". The other reason for multi schemas to win is because I want validate-pyproject-schema-store to be able to support older versions of validate-pyproject for a while while it also provides the extra schema. However, I could remove single schemas for the ones that have extra schemas (just PDM at the moment), so old versions of validate-pyproject would not be able to check PDM, but newer versions would get the full schema and you'd still be able to override these... someday, whenever validate-pyproject-schema-store dropped the single entry points and just pretends that validate-pyproject < 0.24 doesn't exist. (I can't lower cap it because pre-commit always claims validate-project is 0.1).

Of course, we could just ask tools like cibuildwheel to provide multi plugins too. Then the sorting here matters, but I could just name the schema-store plugin something that is unlikely to win (aaa-schema-store for example :) ).

I'm fine with either one, I do feel long term single beating multi might be nicer, while short term multi beating single is better. 99% percent of users will likely be just fine with the schema store and I might be overthinking this.

Thank you very much @henryiii.

It would be nice to have individual packages that provide their own schemas to override "stores" that provide lots of schemas
...
long term single beating multi might be nicer, while short term multi beating single is better.

Alternatively we can also consider the following arrangement:

• "tool" have priority over "multi" (e.g. "tool" priority 1 and "multi" priority 0).
• "multi" plugins can include an optional extra field in the dict, "priority" that overwrites the default value.

That would implement the long-term behaviour you described while allowing the tools themselves to bump their priority when they find relevant.

That would be fine, too.

I have implemented the approach described in #243 (comment).

@henryiii, please let me know if you have any thoughts.

That should work - I can set the priority lower than default for validate-pyproject-schema-store so that more specific plugins override.

Thanks! Trying this out in validate-pyproject-schema-store in henryiii/validate-pyproject-schema-store#117.

Looks like it's working! :) This will also nicely stay out of the way regardless of which one users use, since I set the priorities to -1 and -2.