TEST: Add ohw19 built files from master to source

[emiliom]

... for inclusion as-is in a new set of built pages. See #314.

This PR is not intended to be merged. I'm creating it to continue the discussion in #314, to share the outcome of the current changes. As mentioned there, the ohw19 index page is overwriting the main site index page.

Update 1: I don't know what I did, but the index-page overwrite is no longer a problem! I've now updated the links to ohw19 pages in the Past OHW Events page, but the ohw19 links are not built. Here's one of the warnings:

oceanhackweek.github.io/about/pasthackweeks.md:56: WARNING: 'myst' reference target not found: /ohw19/projects_2019.html

This has to do with files in html_extra_path being handled differently. Apparently links are not generated as expected -- see here. But I haven't found a solution. Note that I tried both /ohw19/ and ../ohw19/, but it made no difference.

Update 2: A simple solution to the link generation problem would be to use "external", absolute url's (eg, https://oceanhackweek.org/ohw19/index.html) instead of relative url's. It makes local debugging harder, but it's very easy.

[netlify]

✅ Deploy Preview for oceanhackweek-preview ready!

Name	Link
🔨 Latest commit	696e99f
🔍 Latest deploy log	https://app.netlify.com/sites/oceanhackweek-preview/deploys/66578148e357650008123420
😎 Deploy Preview	https://deploy-preview-315--oceanhackweek-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[abkfenris]

It looks like we may want to put the built files into _static rather than extra and then use {external} on links to tell Sphinx to not interpret them, but to still keep them as relative links. By using absolute external links we loose the ability to see PR previews (which aren't mission critical for older pages).

[emiliom]

Thanks for that suggestion. I'll test it out and update this PR if it looks promising.

[emiliom]

I placed the ohw19 directory within _static. In conf.py, we already had html_static_path = ['_static'] and the extension attrs_inline needs to be added to myst_enable_extensions](https://myst-parser.readthedocs.io/en/latest/syntax/cross-referencing.html#customising-external-url-resolution).

It didn't work. It looks like myst-nb vers. 0.19 is required, but the version that was used in a conda env (still Py38) I created last week was 0.17.2. During build (make live), this error was emitted at the outset:

ERROR: myst configuration invalid: 'enable_extensions' items not recognised: {'attrs_inline'}

Without adding attrs_inline to myst_enable_extensions, the relative links were use correctly, but the {.external} part was just ignored and passed through as a string. Also, the HTML link was interpreted as a "download" link.

I assume myst-nb vers. 0.19 is not available for Py38, but haven't checked. I suppose I could build a conda env with a recent Python (say, 3.11) and see whether that results in myst-nb >= 0.19 and the feature working as expected ...

[emiliom]

Using a fresh conda env with Py311, a recent myst-nb version was installed and {.external} was interpreted as expected. Links were created correctly. But, the old, Jekyll-based pages were rendered essentially as plain HTML without any styles. Between that and the string token _static being a part of url's, I think it's best to fall back to html_extra_path and just use absolute url's. After all, we're currently using absolute url's for these old pages, anyways! Besides, the old pages will be "rendered" (passed through) as expected, so they can will still be visible locally with make live and on the previews; it's just the links from the "Past OHW Events" page that will be absolute. We can live with that.

[emiliom]

I've pushed the setup I described in my previous comment. The ohw19 pages work as expected.

Let's not merge this just yet, though. I'd like to focus my OHW time right now on getting OHW24 content off the ground. Also, it'll probably be more efficient to bring in the old ohw20 & ohw21 pages into this PR too. ohw18 is best handled in a separate PR, b/c the files reside in a different repo (see #316).