Now that we use a single release pipeline, the API itself might not yet be on
PyPI by the time we build jedi, so we build it locally.
We'll still keep the API docs on PyPI so users can have local autocomplete,
but that path is no longer a dependency for building jedi.
Also explain CHANGELOG synchronization with firmware repo.
Releasing API updates is quite a long and error prone process, so the point
that it was limiting our ability to push frequent updates in practice. There
were 5 tag, commit, wait, and proceed steps and you'd have to start over or
force push if a mistake was made.
This keeps all the npm packages as they were, but versions everything from a
single source of truth, which is this project's main version. Everything
builds on a tag on the main repo, much like we did for a regular IDE docs RTD
release.
It also skips the PyPI for jedi as an intermediate step, which isn't really
needed and required us to have this strict order of publication steps.
We can just let pipx install poetry for us and we don't need a special
Python install or to run `poetry install`.
Also update action versions while we are touching this.
This adds a new javascript package for distributing the pybricks-jedi
Python package and it's dependencies via the npm ecosystem for use in
Pybricks Code.
This splits the Sphinx tag option from SPHINXOPTS. This allows us to
specify the tag without having to remember to add -W and -t. It also
fixes not being able to specify the tag with make.bat on Windows.
While we are touching this, redundant SOURCEDIR uses are removed (main
is already the default) and the .github/workflows/publish-ide-docs.yml
script is fixed (ide directory no longer exists).
With EV3 dropped from the 3.X documentation, the main docs are now nearly identical to the IDE docs, save for some layout changes.
Having just one set of docs is easier to maintain. This drops the IDE doc target.
MathJax uses a CDN to to distribute the package. So in order to use the
docs offline, we would have to include our own copy. But it is a bit
large (50-ish MB), so it is easier to use sphinx.ext.imgmath instead
to generate svg images.
The situation might be different with MathJax v3, but that requires
Sphinx v4.
Laurens Valk
David Lechner
