Add an embedded web server in own workspace #1007
Conversation
(I'm not yet trying to do any fancy monitoring of changes to the files and subsequent regeneration. This is all meant to be very bare bones.) To accomplish this I had to make the main crate callable from other crates, which in turn required some small changes to how it pulls in its own child modules, since `main` can no longer assume it is the crate root.
… blog generation. (trying to make change history here clearer by renaming `main.rs`.)
…enerated content.
|
Just for my own understanding, is there a reason printing the right python command isn't enough for your use case? It seems ok to do this regardless, ultimately, but I would appreciate the insight. |
The I freely admit that one can get the same composition of actions via |
|
Hm, sure. I think even with the watch functionality we'd plausibly be just generating the files on disk and letting the webserver (python or something fancier which might auto refresh browser) handle that part of the puzzle. I'll give it a review code wise for now and merge if it seems good. |
Revisiting #982 by putting the new static site serving code into its own Cargo workspace, to avoid increasing build time for the usual blog authors.
Also took @Mark-Simulacrum 's advice from #982 (comment) and added a message at the end of the default running binary to remind the user about ways they might get their hands a preview of the generated web site.
(I did explore
tiny_httpas suggested by @bjorn3 in #982 (comment) , but it took me a lot more code to get a static site up and running, and I wasn't as confident that my prototype would behave well against "unexpected" urls it received)