This formats return types so they don't look like tuples:
int: deg
If we can figure out how these nodes work, we can create proper links
and maybe use italics for the units or a slightly different font color.
Previously, arguments had "types" like ":ref:`speed`", which would be rendered by Sphinx as a hyperlink and displayed as "rotational speed: deg/s".
This worked well enough but it had a few shortcomings:
- It looks bad on autocomplete, which doesn't know how to render RST with cross references.
- No real type information: int, float, ... ?
- Some units are very long, making the docs less concise.
- The unified approach doesn't always work. Some method arguments can be either deg/s or mm/s, depending on the application. This gets even lengthier.
- It's hard to maintain if you don't know what to link to.
In the new approach, the unit is just added to the type as plain text. Instead of giving the physical signal name, we give the real data type, which is more standard. The physical signal name is usually apparent from the docstring anyway, and can be inferred from the unit as well. This also solves all of the above problems.
Since most Pybricks methods allow both int and float for numeric inputs, we document these as a Number type, which is the union of int and float. Since the type is no longer directly tied to the type, we can still document the return type correctly, since this is never a union.
Instead of having complicated hacks in Sphinx to make this work (I have tried many), it turns out we can conveniently suppress broken references and still display the units. The only downside is that units will no longer have hyperlinks to the signal pages, at least for the moment. We should be able to make on_missing_reference a bit smarter to format the units as we see fit if needed.
The approach here is exemplified in the Motor.run_until_stalled method. Subsequent commits will apply it everywhere. Also clarify the behavior for duty_limit=None while we are updating this code anyway.
Since we changed the acceleration units to mm/s/s, the output values are
fairly large.
The Matrix repr function prints values up to 999, so this avoids
truncating the output.
It is also a good demo of scalar division for a Matrix / Vector.
Fixes https://github.com/pybricks/pybricks-api/issues/94
For Move Hub, this is a breaking change since Move Hub IMU support
was already released. For the other hubs, the IMU API has not been
released yet, so we can do this silently.
This was previously dropped in a2583944d9
but it was added in again in c666009511.
Since this module was never included in a release (it was hidden),
it is OK to do this.
Prior to every previous release, we we had to delete certain
features that did not make it into the release. This lets us
do that with a tag instead. This way we can keep a clean git
history that is easier to follow.
Version tags can be useful to keep track of new or updated features.
This lets us hide such details in the documentation that ships with the IDE to keep it concise.
We were not using a proper release for sphinx-rtd-theme
in order to work around some bugs. Meanwhile, a proper
release has come out, so let's upgrade to 1.0.0.
Also bump Sphinx to 4.4.
Also update and fix workarounds for cross references.
Fixes https://github.com/pybricks/pybricks-api/issues/98.
- Use isometric projection
- Fix broken plug
- Use correct background color
While we are at it, add colors to show which 9 colors this device supports.
Override typed docstrings in order to hide types like SupportsFloat and SupportsComplex.
Avoid use of ``real`` and ``imag``, since both ``a`` and ``b`` can be
either.
Also reduce number of overloads by letting ``b`` default to 0, which is true in practice.
See also https://github.com/pybricks/pybricks-api/issues/84
This way we can do the following, which is useful if it cannot be expressed in terms of other requirements.
.. pybricks-requirements:: movehub
A good example is on the specific hub page itself. The Move Hub requires the Move Hub.
We will work on a version that can be toggled dynamically. It will just include this static version. This keeps things simple and still lets
us use the static version as needed.
This simplifies the table and reduces its size.
Also copy assets manually since Sphinx does not automatically copy
images to _images when used for custom directives.
This was the only remaining section under "extras", so it is better to have it elsewhere. Since it only applies to the Pybricks package, put it there.
Also rename Pybricks Modules heading to Pybricks Package, since it behaves more like a package in contrast with the MicroPython modules that we now document as well.
Based on user feedback, we learned that the control attribute is used more frequently than anticipated. Therefore it makes sense to document it here, just like we do with instances of pybricks.common classes in hubs.
This makes it a bit easier to find and see how it is used, along with some of the existing examples.
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.
The `only` directive can be used to include content selectively. It cannot be used to select a different TOC, which is why we resorted to separate doc builds before.
Now that we have dropped EV3 references from the docs, we can use a single build and just customize the content on the landing page with the only directive.
The docs can now be built with:
# Main docs:
make -C doc html SPHINXOPTS=-tmain
# IDE docs:
make -C doc html SPHINXOPTS=-tide
This can be traced back to 0013a74d72 and 92e3735d63.
It was used to work around things like
sound.beeps(number)
Description
being incorrectly displayed as
classmethod sound.beeps(number)
Description
But the current version of sphinx appears to display this correctly even without the hack. We want to reduce the number of hacks because they tend to break updates (https://github.com/pybricks/pybricks-api/issues/69#issuecomment-879822417).
Laurens Valk