Kernel docs followups

[sayakpaul]

• Move to a fully Jinja-based template and remove re based parsing.
• Decouple commands into two: kernels init-card and kernels fill-card.
• Make kernel card generation a part of kernels upload (and test).
• Add an entry for generating kernel system cards to the "writing kernels" tutorial.

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[sayakpaul]

@danieldk I have broken the create-and-upload-card command into two simpler commands as we discussed internally. I would like to get a review on the progress made so far before making further changes (docs, etc.).

Would like to open a PR to this PR branch for nix build . so that the card generation process gets included in its execution? That way, once kernels upload is issued, the card also gets uploaded to the build repo.

[sayakpaul]

@danieldk @drbh a couple of updates here:

• Broadly, it's now decoupled into two commands: kernels init-card ... and kernels fill-card.
• Existing user section preserved whilst build-based info is always updated when relevant.

Question:

Do we have to assume "build" directory exists within a kernel source directory? Asking because it seems like we can initialize and serialize the kernel card as "CARD.md" in the top-level kernel source dir and then fill it up based on the information available from build.toml.

[sayakpaul]

@danieldk I have some questions.

I did remove repo_id from fill-card. But how do we load an existing card from the Hub if repo_id isn't present in either init-card (that is what I am getting at after #287 (comment)) or fill-card?

If we were to just serialize the card template in the source repo (e.g., https://github.com/huggingface/kernels-community/), then repo_id would need to be removed from there (which is fine). However, if we also remove repo_id from fill-card, then there is no way for us to load an existing card from the Hub.

If we add repo_id back in fill-card, then I am guessing we'd only want to use it to load an existing card?

In any case, information that depends on build or metadata will be updated each time a new build is obtained and the fill-card utility is called (when needed). So, even if we're operating on an already loaded card, user-content won't be affected.

[danieldk]

I did remove repo_id from fill-card. But how do we load an existing card from the Hub if repo_id isn't present in either init-card (that is what I am getting at after #287 (comment)) or fill-card?

What is the use-case for loading an existing card? The way I see it, you get your initial card template through init-card (or maybe even kernel init in the future). If someone wants, they can make some changes to the template, like adding extra sections, etc. and then they commit it to the GitHub repo. At that point the user does not have to do anything with the card anymore, since the card gets filled (not in the repo, but in the build output) and uploaded. When would they have to load an existing card from the Hub?

If we were to just serialize the card template in the source repo (e.g., https://github.com/huggingface/kernels-community/), then repo_id would need to be removed from there (which is fine).

But it can still be in the description like this

This is the repository card of {repo_id} that has been pushed on the Hub. It was built to be used with the [`kernels` library](https://github.com/huggingface/kernels). This card was automatically generated.

right? Since we can fill it from the repo_id in build.toml. Of course, if the kernel developer did not define repo_id, then we cannot fill it for them and we probably need a slightly different description.

However, if we also remove repo_id from fill-card, then there is no way for us to load an existing card from the Hub.

As I mentioned above, I don't understand when one would want to load an existing card from the Hub?

[sayakpaul]

Sounds good.

Then WDYT about repurposing this PR to:

• Include initialize_card() in kernels init. I think it's better that way?
• Modify fill-card so that the builder can use it to produce a build/CARD.md to upload to the Hub as a README.md. This will be opinionated, meaning if users update stuff afterward, it won't be used in the next build.

[sayakpaul]

I have updated the PR in accordance with #287 (comment).

@drbh @danieldk PTAL when you have time.