Shipping to distros

[LecrisUT]

No description provided.

[henryiii]

And #9 should reduce fights with the formatter (I think it wanted to reformat the footnote incorrectly).

[LecrisUT]

pre-commit is actually complaining quite a bit on this:

• MD001: these can be actually stylistic choices
• MD004, MD024, MD025, MD045: conflicts with marp, should disable in slides/*. I don't know how to do that though

Although I quite like what rumdl provides, seems more stable than mdformat. How far have you looked into it?

[henryiii]

This is only the second repo I've tried rumdl on, I think. On a pure mystmd site it works pretty well (better than prettier).

[henryiii]

🤖 AI text below 🤖

Pushed a fix for the pre-commit complaints.

Marp conflicts (MD001/MD004/MD024/MD025/MD045): I first scoped these out of slides/** with [per-file-ignores]. rumdl check honors that, but rumdl fmt doesn't — while fixing an unrelated rule it re-serializes the construct and applies the "ignored" rules anyway (e.g. demoting per-slide # titles to ##, which changes how Marp renders them). Since the pre-commit hook runs rumdl-fmt, that's the "fights with the formatter" problem in a worse form. So I've excluded slides/ entirely via exclude = ["slides"] — decks are hand-authored Markdown + Marp directives and don't benefit much from the linter anyway.

Minimal repro of the fmt bug (0.2.27):

# .rumdl.toml
[per-file-ignores]
"slides/**/*.md" = ["MD004"]

<!-- slides/deck.md -->
# Title

text
- parent
  * child

rumdl check reports only MD032 (MD004 suppressed ✅). rumdl fmt reports "Fixed 1/1 issues" (the MD032 blank line) but also silently rewrites * child → - child — MD004 applied despite the ignore. I'll file this upstream.

Real content issues (not Marp-related): fixed in content/other-tools/04_distros.md — wrapped the bare footnote URL as <https://packaging.lecris.dev/> (MD034) and promoted ### Why get involved? to ## so it's a sibling of ## Participating as upstream (MD001).

prek -a is clean now.

[LecrisUT]

Ok, checked again with MD001 on the myst page, and it did not make much of a difference (was hoping that it got skipped in the right TOC), so I guess fine as is. Guess all good now, and will move on to the next ones

[LecrisUT]

No idea why the deploy failed

Creating Pages deployment with payload:
{
	"artifact_id": 8061769255,
	"pages_build_version": "83c01b5c41e57916c6239cb87fb2fc847346fa88",
	"oidc_token": "***"
}
Created deployment for 83c01b5c41e57916c6239cb87fb2fc847346fa88, ID: 83c01b5c41e57916c6239cb87fb2fc847346fa88
##[debug]{"id":"83c01b5c41e57916c6239cb87fb2fc847346fa88","page_url":"https://scikit-build.org/SIMPLE-Py/","status_url":"https://api.github.com/repos/scikit-build/SIMPLE-Py/pages/deployment/status/83c01b5c41e57916c6239cb87fb2fc847346fa88","preview_url":""}
Getting Pages deployment status...
Error: Deployment failed, try again later.
##[debug]Node Action run completed with exit code 1
##[debug]Set output page_url = https://scikit-build.org/SIMPLE-Py/
##[debug]Finishing: Deploy to GitHub Pages

status.github.com page is all green, but that status_url is giving a 404. Hopefully it will recover and it's not just GitHub randomly changing its API endpoints