New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add static hosted HTML page with PR builder forms #968
Comments
If I understood correctly:
If this works, it could also be a nice workflow for 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.
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 Of note: that repo is slooooow to work with, and might benefit from a performance-focused implementation. Indeed, going from
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 "$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 |
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
The text was updated successfully, but these errors were encountered: