Open bollwyvl opened 3 months ago
If I understood correctly:
If this works, it could also be a nice workflow for conda-forge-repodata-patches-feedstock
(assuming we can start with existing files).
Also, this doesn't need any changes in conda-forge.github.io either, right?
PS: We do have a single JSON with all packages and feedstocks at https://github.com/conda-forge/feedstock-outputs/tree/single-file. Would that be a good starting point for the autocompletion schema?
Alternatively, provided we do generate the schemas here (so they are close to the code that ingests them), we can also add a couple pages to the website so everything "JavaScript-y" is defined in the same repo. And if we go down that route for the repodata patches repo, I'd assume there are several bits of code that would be shared.
Well, the nice thing about JSON schema is it's not just JavaScript-y (or GitHub-y, pydantic-y, or whatever) and pretty much gives the same results in all the implementations.
But yes, the workflow would be entirely offline, static, running in the browser, but supported by all the engineering rigour we can throw at the process.
The "end product" is using pre-existing HTML URL features, so the user would be prompted in a non-scary way to do a standard GitHub login when they click on the link to propose the file, which then immediately suggests the PR workflow.
repodata patches repo
This would be possible as well, but that generated schema is gnaaarly, and would probably take some work to clean it up for human consumption. Both pydantic
and msgspec
support JSON Schema, but only the parts they want to.
Of note: that repo is slooooow to work with, and might benefit from a performance-focused implementation. Indeed, going from pydantic
to msgspec
would probably cut the runtime of that repo in half, if not more.
https://github.com/conda-forge/feedstock-outputs/blob/single-file/
At rest, no, that is just... some unlabeled JSON, which would require special JavaScript-y parsing to deal with effectively. If it was instead stored as a reusable, self-describing schema fragment (as described), and hosted at a generally-resolvable URL it could help in a number of places.
Of course, this falls down when one wants to use the values from the enum
as the keys of a dict... schema only offers pattern
, which would be a mighty regex indeed:
"$defs": {
"a-valid-conda-forge-feedstock-name": {
"type": "string",
"pattern": "^(aalto-boss|a-few-more|zziplib)$"
}
}
As for the outputs, I would probably make that a whole separate enum
schema.
Comment:
elevator pitch
Provide a low-barrier way to make precise, pre-validated admin requests.
motivation
After looking at the GH PR templates feature (suggested in #535), I was unsatisfied with the specificity of the language (as usual, not quite JSON schema),
design ideas
So I wrote a thing that:
Here's a demo for an outrageously long schema:
https://deathbeds.github.io/jupyak/shaver.html
challenges
The downside: to get the nice UI (dropdown/autocomplete), all the feedstock names would need to be embedded in the schema, e.g.
But this might be something that could be generated in one place...
And then referenced here:
implementation ideas
After the... experience... with
pydantic
over onconda-smithy
, it seems like schema-first design (but perhaps authored in YAML) to get to a well-typedTypedDict
might be easier and give strictly better validation.alternatives