Separate code and autogenerated data

[not-my-profile]

I think examples and stats_website should both live either in another branch or another repository, so that updates to them do not clutter up the commit history of the main branch of this repository.

[AlexWaygood]

I agree that this isn't ideal. However, I'm inclined to keep things as they are for now.

Firstly, the current implementation is simple, works pretty well AFAICS, and fits my brain very well.

Secondly, not all files in the stats_website directory are autogenerated: big_logo.png, index.md, logo.png, serialize.md and stats-csv.md are all nongenerated.

Thirdly, at some point it might be nice to convert some of the stuff in scripts/regenerate.py into an actual plugin for mkdocs or mkdocstrings (Not one uploaded to PyPI, just one that would live in this repo). Not sure it makes much sense to make changes here until I've looked at that properly.

So: "maybe, but not right now".

[not-my-profile]

I'd love to contribute some improvements to the website, but I don't want to touch a repository that's actively using autogenerated commits ... but it's not a pressing matter, I am quite busy with other projects anyway.

Ad 2: Not a problem files can easily be copied.
Ad 3: I don't really see why this project should generate Markdown at all, or use a static-site generator. I think it makes more sense to directly generate HTML.

[AlexWaygood]

Ad 3: I don't really see why this project should generate Markdown at all, or use a static-site generator. I think it makes more sense to directly generate HTML.

Yeah, quite possibly. Again, it was sort of a "hey, this works! Let's do it!" kind of thing. If it's useful for other people then that's awesome, but this is basically a hobby project for me first and foremost. I'm mostly here to have fun 😀

[not-my-profile]

Oh I just realized that the website also includes the API documentation, which you generate with mkdocs? That's quite nifty :), so using mkdocs does probably make sense.

[AlexWaygood]

I'd love to contribute some improvements to the website, but I don't want to touch a repository that's actively using autogenerated commits ...

Separate to the principle of the thing (which I agree you're correct on, the autogenerated data should indeed be more cleanly separated from the code in an ideal world) — what exactly is your concern here, out of curiosity? Security issues? Concern that you might accidentally edit a file that's meant to be generated?

[AlexWaygood]

You'll be pleased to know that, following #82, none of the MarkDown files in the stats_website/ directory are generated anymore (the pages are now generated transparently as part of the mkdocs build, using the mkdocs-macros plugin). The examples/ directory and stats_website/stats_as_csv.csv remain generated, for now.

[not-my-profile]

what exactly is your concern here, out of curiosity?

I like to put effort into my commits to make the git log as readable as possible and don't really feel compelled to do so when the repository is actively using autogenerated commits.

Sidenote: git log also doesn't have an easy way to exclude an author but even if it did, many people probably browse the log via the GitHub web interface which also doesn't have this functionality.

[AlexWaygood]

I like to put effort into my commits to make the git log as readable as possible and don't really feel compelled to do so when the repository is actively using autogenerated commits.

Very fair, I get that! There will be fewer autogenerated commits now. I'm continuing to work on getting them down to 0.