Removed references to non-existent notebooks. #188
Conversation
|
Actually, while on this topic, a separate but related question is about versioning the docs. The docs are versioned in that they are "standalone" (a single, self-contained directory that just needs to be served) and have the version number "inside them":
However, (a) that's not very obvious, and (b) we don't keep around previous versions. I've always imagined doing something like what bokeh does, unless that doesn't seem good to you? On your hosting provider for geoviews, could you do something along the lines of uploading the docs to a folder like If that seems reasonable, we could make nbsite support that kind of workflow. |
I would very much like this for all our projects. The main disadvantage I see is the increased storage costs on S3 as the number of versions grow. Though we could institute a policy of having the docs only ever going back two versions (say) if we feel the need to keep it bounded. |
|
Yes we should definitely start versioning docs. I can start doing the uploads to our S3 buckets that way, but it would also be nice to add a toggle to switch between the different versions like bokeh has. |
Agreed. And that is something that should be supported at the nbsite level as well. I've opened this nbsite issue on this topic: holoviz-dev/nbsite#54 |
The
rm ...in travis is why the doc build failed for the last tag push.This reminds me...I can't remember if the doc build for geoviews is doing what you want now:
You could build the docs locally, too, if you were working on the docs specifically
(*). (Could also set it up so pushing a special tag, e.g. 'doc-build' or whatever, updates another site e.g. https://ioam-docs.github.io/geoviews-tmp/ or something like that.)(*)Not quite there yet, but there will be a simple nbsite command to run locally for that soon, I hope. But for the purposes of deciding if the options cover what you want, please pretend it exists.