| Crates.io | snakedown |
| lib.rs | snakedown |
| version | 0.2.0 |
| created_at | 2025-06-10 05:52:46.258009+00 |
| updated_at | 2026-01-11 14:58:14.401909+00 |
| description | This is a snakedown. Hand over your docs, nice and clean, and nobody gets confused. |
| homepage | |
| repository | https://github.com/savente93/snakedown |
| max_upload_size | |
| id | 1706688 |
| size | 402,400 |
A Python API extractor written in Rust. I got frustrated with the standard tools used for documentation generation used in Python, namely that all of the ones I've worked with have at least one of the following to characteristics:
serve functionality)Number 1 is particularly a concern for packages that are slow to import, or have a convoluted structure (which is the case for some packages I work with)
There are many excellent Static Site Generators like Hugo or Zola that are fast and offer a much better experience when developing. Typically, documentation are static pages so they should be a perfect fit, except for one issue: automatic API reference generation. This was a big showstopper... until now!
SnakeDown is an experiment to get to a place where using Hugo or Zola for python documentation generation is a viable option.
(Currently mostly for shits and giggles, but who knows.)
While the project might not cover all of these goals yet, these are some of the things I try to keep in mind when working on SnakeDown (in loose order of precedence):
Currently, SnakeDown is solidly in the MVP state. While I am quite happy with it so far, you use it at your own risk. That said, I always welcome bug reports and feature requests if you do decide to try it! Below is a loose planning of the features I want to work on
(subject to change)
snakedown init to setup snakedown.toml etc.snakedown doctor to help diagnose problemsview on <SCM> buttonNo. It is a personal project for the time being so while there may be persiods of inactivity, I intend to keep working on it until it serves my personal needs. (Poe's law dictates that I mention this is mostly a joke. It's a common question for FOSS projects that don't have the high velocity of larger projects and this is a tongue in cheek way of beating this question to the punch)
To quote one of the giants in our field BurtnSushi:
ripgrep is a project whose contributors are volunteers. A release schedule adds undue stress to said volunteers. Therefore, releases are made on a best effort basis and no dates will ever be given.
An exception to this can be high impact bugs. If a ripgrep release contains a significant regression, then there will generally be a strong push to get a patch release out with a fix. However, no promises are made.
(source: ripgrep)
The same applies to SnakeDown.
Three main reasons:
Not yet, but I suspect they will.
This repo was initially setup using cargo-generate and this template