-
Notifications
You must be signed in to change notification settings - Fork 66
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
[MNT,DOC] use latest code in builds of the docs with RTD #472
Conversation
hi @stevejpurves! I'm testing this PR but I'm getting this error:
it seems that I'm facing the same problem when testing this inside Read the Docs. |
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 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'll let you know when we deploy these changes to production in beta so you can start testing this and giving us some feedback 😍 |
@humitos that's great, thank you! do you have a rough ETA on those changes making it to prod/beta? |
Not yet. We are currently working to make this happen. |
Hi! We already deployed these changes. You should be able to use |
That's great news @humitos !! @stevejpurves just lemme know if you'd like me to take a look or provide feedback on something! |
ok, RTD build is green now. Guess I am surprised by Going to do a little more to try and make local dev cycle, nicer while keeping RTD up |
4555307
to
51f0c8f
Compare
There was a problem hiding this 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'): |
There was a problem hiding this comment.
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 🤔
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
examples/demo-active.html
Outdated
@@ -14,10 +14,12 @@ | |||
}, | |||
} | |||
</script> | |||
<!-- uncomment to use latest thebe release |
There was a problem hiding this comment.
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>
```
:::
@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 | ||
|
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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
webpack.config.js
Outdated
publicPath: "https://unpkg.com/thebe@" + pkg.version + "/lib/", | ||
publicPath: process.env.NODE_PREPUBLISH | ||
? "_static/lib/" | ||
: "https://unpkg.com/thebe@" + pkg.version + "/lib/", |
There was a problem hiding this comment.
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", |
There was a problem hiding this comment.
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
Co-authored-by: Chris Holdgraf <[email protected]>
…hebe into mnt/docs-use-latest-clean
@choldgraf there is still a lot to be desired about the build process here. It's complicated by trying to build for the |
sounds good - just a quick thought, could we deprecate one of the build processes if it is somewhat redundant? E.g., could we:
Would that simplify? |
ok we are good to go on this one now! |
There was a problem hiding this 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?
docs/contribute.md
Outdated
make js-dev | ||
``` | ||
|
||
for a development build. |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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
Ping for @stevejpurves - I see you've still got this in "needs review", are you hoping for 👀 from others on the team? |
Co-authored-by: Chris Holdgraf <[email protected]>
@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. |
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! 💪🏼 |
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:
docs/_static