review/suggestions and 🪄 for #20121 #20227
Conversation
ecormany
left a comment
ecormany
left a comment
There was a problem hiding this comment.
This all seems fine, but I would definitely like another engineer to take a look too!
There was a problem hiding this comment.
Yes, correct to get rid of this one. The only casualty at this point is automatic build of the hardware API docs. I believe @SyntaxColoring advocated for us to keep generating them back when I removed the v1 and OT-One docs from CI. If we still want them on the web, we can and should bring them to mkdocs as well.
There was a problem hiding this comment.
This one is over my head. What does this file do for us?
There was a problem hiding this comment.
ya this is the magic it took to get the build to work, ignore it.
| ("py:class", r"optional"), | ||
| ("py:class", r"ModuleContext"), | ||
| ("py:class", r"DeckLocation"), | ||
| ("py:class", r"MeniscusTrackingTarget"), | ||
| ("py:class", r"NozzleLayout"), | ||
| ] | ||
|
|
||
| nitpick_ignore = [ | ||
| ("py:exc", "LiquidClassDefinitionDoesNotExist"), | ||
| ("py:exc", "UnexpectedTipRemovalError"), |
There was a problem hiding this comment.
We need these to get in edge for the Sphinx docs to build right now — maybe should do as a separate PR.
There was a problem hiding this comment.
For sure what you think is best.
There was a problem hiding this comment.
🤷♂️ to these small changes. If we want to tear out the old Sphinx PAPI v2 docs, we should delete the whole api/docs/v2/ directory.
| "opentrons", | ||
| "opentrons-shared-data", | ||
| ] | ||
|
|
||
| [tool.uv.sources] | ||
| mkdocs-parent-css-plugin = { path = "mkdocs-parent-css-plugin", editable = true } | ||
| opentrons-shared-data = { path = "../shared-data", editable = true } | ||
| opentrons = { path = "../api", editable = true } |
There was a problem hiding this comment.
This is what got me into trouble last week…uv sync kept failing with exactly this setup (or maybe not quite exactly…does order matter in listing dependencies? i had them alphabetical). But this seems to work, so let's try it.
| Returns: | ||
| The loaded and initialized module: a | ||
| ModuleTypes: The loaded and initialized module, which may be a |
There was a problem hiding this comment.
This doesn't seem to be a problem for mkdocs rendering, so this is effectively a docs change.
There was a problem hiding this comment.
Ya take or leave, just noticed the type did not match the code.
|
So I think if all we want to do is have becomes What we do with that hardware docs output is an open question. |
Soooooo
make -C api docswork... does that even matter? Just wanted to see what it did to fix that.api/src/opentrons/protocol_api/protocol_context.pywhich seems like a legitimate correction