Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MNT,DOC] use latest code in builds of the docs with RTD #472

Merged

Conversation

stevejpurves
Copy link
Collaborator

@stevejpurves stevejpurves commented Sep 7, 2021

This PR aims to address #285 and change the default docs build to always use the version of thebe represented by the latest code in the repo. Previously the docs would load the latest published version from unpkg.

TODOS:

  • add makefile commands to build the docs locally, and place a copy in docs/_static
  • update docs to use the local build
  • update readthedocs builds as needed and ensure that these build with the latest local thebe

@stevejpurves stevejpurves changed the title [MNT,DOC] use latest code in builds of the docs with RTD [MNT,DOC] use latest code in builds of the docs with RTD - DRAFT Sep 7, 2021
@humitos
Copy link

humitos commented Sep 16, 2021

hi @stevejpurves! I'm testing this PR but I'm getting this error:

repos/thebe/docs  pr/472 ✗                                                                                                             2m ⚑  
▶ make html
rm -rf _static/lib
cd ..; yarn install --frozen-lockfile; yarn build
yarn install v1.22.11
[1/5] Validating package.json...
[2/5] Resolving packages...
error Your lockfile needs to be updated, but yarn was run with `--frozen-lockfile`.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
yarn run v1.22.11
$ webpack --mode development --progress
/bin/sh: line 1: webpack: command not found
error Command failed with exit code 127.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
make: *** [Makefile:43: js] Error 127
Time: 0h:00m:03s

it seems that yarn is not installing the dependencies and failing. I don't have too much experience with yarn and I'm not sure if it's possible to remove --frozen-lockfile argument.

I'm facing the same problem when testing this inside Read the Docs.

@humitos
Copy link

humitos commented Sep 16, 2021

For the record, I was able to make this PR work with the new Read the Docs Docker images and config file (see readthedocs/readthedocs.org#8453, readthedocs/readthedocs.org#8478, and readthedocs/readthedocs-docker-images#107) with the following changes.

Read the Docs configuration file

# readthedocs.yml
version: 2

python:
  install:
    - requirements: docs/doc-requirements.txt

build:
  os: "ubuntu20"
  languages:
    python: "3.9"
    nodejs: "14"

Note the usage of build.os and build.languages (these name may change, we are still discussing them); but this is going to be the way to install nodejs, for example.

Sphinx configuration file

# docs/conf.py
path_root = Path(__file__).parent.parent
os.environ['PATH'] = f'{path_root}/node_modules/.bin/:' + os.environ["PATH"]

run(["npm", "install", "yarn", "jsdoc"], cwd=path_root)
run(["yarn", "--version"], cwd=path_root)
run(["yarn", "install"], cwd=path_root)
run(["yarn", "build",], cwd=path_root)
sh.copytree(f"{path_root}/lib", "_static/lib")

Highlights:

  • I'm adding local node_modules/.bin to the PATH environment variable
  • I removed the --frozen-lockfile
  • I'm installing jsdoc that's required (not available by default in new Docker images)
  • There is no need to call node_modules/yarn/bin/yarn, just yarn works

I'll let you know when we deploy these changes to production in beta so you can start testing this and giving us some feedback 😍

@stevejpurves
Copy link
Collaborator Author

stevejpurves commented Sep 16, 2021

@humitos that's great, thank you!

do you have a rough ETA on those changes making it to prod/beta?

@humitos
Copy link

humitos commented Sep 20, 2021

do you have a rough ETA on those changes making it to prod/beta?

Not yet. We are currently working to make this happen.

@stevejpurves stevejpurves mentioned this pull request Sep 20, 2021
8 tasks
@humitos
Copy link

humitos commented Sep 29, 2021

Hi! We already deployed these changes. You should be able to use build.os and build.tools as I mentioned in #472 (comment). Please, let me know if it works for you! 💪🏼

@choldgraf
Copy link
Collaborator

That's great news @humitos !!

@stevejpurves just lemme know if you'd like me to take a look or provide feedback on something!

@stevejpurves
Copy link
Collaborator Author

stevejpurves commented Oct 4, 2021

ok, RTD build is green now. Guess I am surprised by yarn install seemingly cleaning out the node_modules directory and making yarn, jsdoc subsequently unavailable. With or without the frozen-lockfile option. I can't reproduce this locally, but that's the apparent behaviour on RTD.

Going to do a little more to try and make local dev cycle, nicer while keeping RTD up

@stevejpurves stevejpurves self-assigned this Oct 4, 2021
@stevejpurves stevejpurves force-pushed the mnt/docs-use-latest-clean branch from 4555307 to 51f0c8f Compare October 4, 2021 13:28
@stevejpurves stevejpurves requested a review from choldgraf October 4, 2021 16:05
@stevejpurves stevejpurves changed the title [MNT,DOC] use latest code in builds of the docs with RTD - DRAFT [MNT,DOC] use latest code in builds of the docs with RTD Oct 5, 2021
Copy link
Collaborator

@choldgraf choldgraf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This in general looks pretty nice to me! Just a few comments about the build process and the docs, happy to take another look or iterate on comments! Thanks @stevejpurves for doing this work :-)

# during development and testing
path_root = Path(__file__).parent.parent

if os.environ.get('READ_THE_DOCS'):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reason for having two different workflows on RTD vs. locally? I'm wondering if it'd be possible to just have one check for whether the _static/lib folder exists rather than making it build environment-specific 🤔

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point @choldgraf.

I'm seeing the RTD process as separate mostly due to the unique setup it needs i.e. because of the local installs of yarn and jsdoc which are typically going to be global installs in someone's local development environment. We don't want two versions of these kicking around locally, or to add them to the developer's path.

I have separated that environment setup from the build commands, where the latter are now a run based on a check for the _static/lib in both environments as you suggested.

Note in the course of this I've picked up on some more changes that were needed to properly support the "use local build" both locally and on RTD. see changes to Makefile and webpack.config.js.

if os.environ.get('READ_THE_DOCS'):
node_modules_bin = f'{path_root}/node_modules/.bin/';
os.environ['PATH'] = f'{node_modules_bin}:' + os.environ["PATH"]
run(["npm", "install", "yarn", "jsdoc"], cwd=path_root)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we could use tox or nox to handle the environment installs for these steps 🤔 but I don't think it needs to block this PR

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm open to it @choldgraf but don't understand how it fits yet. With this library being primarily driven by a js/yarn build process, would it help? as this wouldn't be included in any virtualenv dependency management (or does that go beyond python dependencies?). I've not used tox or nox though so happy to chat about this to get a better understanding.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just as a point of info - nox supports conda environments so you can use it with JS-style build systems, which is pretty nice. But I don't think it needs to block this! For example: https://github.com/pydata/pydata-sphinx-theme/blob/master/noxfile.py

@@ -67,7 +67,7 @@ Example
},
}
</script>
<script src="https://unpkg.com/thebe@latest/lib/index.js"></script>
<script src="../_static/lib/index.js"></script>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmmm - is it the case that these example HTML files will never work unless they are in the _static folder (since the library won't be in the right path otherwise)? If so, then why don't we just put the whole folder in _static/html_examples and add lots of links to that folder in docs + README so that people discover it?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would simplify that path, as we would be loading from ../lib/index.js as per the other pure HTML examples that we are copying.

In this case this example needs sphinx to compile it to HTML first -- I'm not clear on how or when to move the result of that build into the HTML though?

@@ -14,10 +14,12 @@
},
}
</script>
<!-- uncomment to use latest thebe release
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could we just add this as a note in the docs + README, rather than putting it in a single example? e.g.

:::{admonition} Use the latest release of `thebe` on unpkg
:class: tip
These examples build a _local_ version of `thebe` in order to show off the latest features.
If you'd like to instead load the latest _release_ of Thebe, replace the `<script>` elements with the following:

```html
<script type="text/javascript" src="https://unpkg.com/thebe@latest"></script>
```
:::

@choldgraf
Copy link
Collaborator

@stevejpurves is this one blocked on anything? Just wanna make sure that you're not waiting for others for something

js-dev: clean-js
cd ..; yarn install; yarn build
cp -R ../lib _static/lib

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New js build rules provided but not invoked by default

@@ -7,10 +7,11 @@
"build": "webpack --mode development --progress",
"build:prod": "webpack --mode production",
"build:watch": "webpack --mode development --progress --color --watch",
"prepare": "yarn run build:prod",
"prePublishOnly": "NODE_PREPUBLISH=true yarn run build:prod",
Copy link
Collaborator Author

@stevejpurves stevejpurves Oct 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added environment var to identify npm publish action in webpack.config.js

publicPath: "https://unpkg.com/thebe@" + pkg.version + "/lib/",
publicPath: process.env.NODE_PREPUBLISH
? "_static/lib/"
: "https://unpkg.com/thebe@" + pkg.version + "/lib/",
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

publicPath is used by webpack to load the thebe's chunked js package. Previously a local build would have been loading remaining chunks from the last version on unpkg.

Now we always set this path to use a local thebe build, both in local development and on RTD. When publishing the package to npm this should revert to the previous unpkg path which is correct for official releases.

package.json Outdated
"fmt": "prettier --trailing-comma=es5 --write *.js src/*.js examples/**/*.js test/*.js",
"serve": "http-server -c-1 -a 127.0.0.1 -o development/binder.html",
"serve:local": "http-server -c-1 -a 127.0.0.1 -o development/local.html",
"serve:examples": "node setupExamples.cjs; http-server -c-1 -a 127.0.0.1 -o examples/index.html",
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added a serve command to make html examples useful in local development

@stevejpurves
Copy link
Collaborator Author

@choldgraf there is still a lot to be desired about the build process here. It's complicated by trying to build for the examples folder, the docs and RTD consistently. This is working but there are some parts that could be improved for sure.

@choldgraf
Copy link
Collaborator

sounds good - just a quick thought, could we deprecate one of the build processes if it is somewhat redundant? E.g., could we:

  • put the examples/ folder inside of docs/
  • serve that folder as a static asset with our docs (so HTML pages are just direct copied through)
  • have them re-use the same thebe bundle that is packaged for use with docs/

Would that simplify?

@stevejpurves stevejpurves linked an issue Oct 18, 2021 that may be closed by this pull request
@stevejpurves
Copy link
Collaborator Author

ok we are good to go on this one now!
I'd like to get this one in, bring in dependabots, test and cut a new release

Copy link
Collaborator

@choldgraf choldgraf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This in general looks good to me (one minor suggested change and I'm +1 once those are resolved)! How long has it been since we cut a release? Maybe we should release, then merge this, and have a bit of time to see if there are regressions?

make js-dev
```

for a development build.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you explain here what the difference is? When would somebody use a development build vs. just make js?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

have moved that line and added a note @choldgraf

if os.environ.get('READ_THE_DOCS'):
node_modules_bin = f'{path_root}/node_modules/.bin/';
os.environ['PATH'] = f'{node_modules_bin}:' + os.environ["PATH"]
run(["npm", "install", "yarn", "jsdoc"], cwd=path_root)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just as a point of info - nox supports conda environments so you can use it with JS-style build systems, which is pretty nice. But I don't think it needs to block this! For example: https://github.com/pydata/pydata-sphinx-theme/blob/master/noxfile.py

@choldgraf
Copy link
Collaborator

Ping for @stevejpurves - I see you've still got this in "needs review", are you hoping for 👀 from others on the team?

@stevejpurves
Copy link
Collaborator Author

@choldgraf just checking back on the master branch and this PR in addition to improving the doc build process, also contains a number of improvements and a few small fixes to the dos themselves. With a few apparent errors on there and the fact I have to change the docs to the local build manually to be able to test anyways....(!) means I think it's best to get this in and then cut a release.

The changes to the library itself are really limited, it's mostly about build and the docs, so risk of regressions should be minimal. Happy to jump onto testing of a release straight away once it's up on unpkg.

I'm going to bring this in and proceed on that basis, we can always cut a release from the previous commit is we decide that's really needed.

@stevejpurves stevejpurves merged commit 65800aa into jupyter-book:master Oct 25, 2021
@humitos
Copy link

humitos commented Oct 25, 2021

I'm happy that this got merged! 🎉 Let me know if everything continues going well on Read the Docs or if you have any other feedback! 💪🏼

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use the latest thebe.js in our documentation
3 participants