I'm getting close to a working version of the jupy...
# plugins
l
I'm getting close to a working version of the jupyter book plugin. One thing I'm trying to add is the option for plugins. In the pytest plugin you do that by adding plugins to
pants.toml
, can anyone point me to how that is implemented? I.e. how to read the
pants.toml
and then add those dependencies to the rules? I have a rough idea of how to implement it, but it would be helpful to understand the way it's already being done.
b
Options handling is done for you (and they work at the pants.toml, CLI, and env var levels). All you need to do is declare attributes using types in option_types.py and they'll get collected. Check our one or more of your favorite subsystem classes for examples
l
Perfect. will do
b
Oh man. You mean the option for book plugins don't you ๐Ÿคฆโ€โ™‚๏ธ
I'm so sorry. It's early ๐Ÿ˜… Look at flake8. That's probably the "simplest" start I would assume.
l
haha yeah. But I'm taking @enough-analyst-54434's advice and keeping it simple to start. I think if I define the plugins' package in the target so that those dependencies are already installed when I run
jupyter-book
then it should work.
b
Also "plugins" is overloaded ๐Ÿ˜” The flake8 pants plugins supports in-repo flake8 plugins as well as third party ones (which really "just work" since the python ecosystem already handles that)
I don't know the nuance of Jupiter book, but I'd assume people would be adding plugins to the environment the tool is running in, similar to flake8 and pytest
l
yup, exactly
b
In that case, keep modeling after flake8 and you're golden.
l
ok. I'll take a look at that. I tested hardcoding the required plugin to the
PexRequirements
along with
jupyter-book
and that works.
b
Flake8 also allows loading in-repo plugins. I'm not sure we have any tools that are extendable that don't. If that's a feature of Jupiter book, fell free to copy that over too. Or not if you want to be incremental. Dealers choice ๐Ÿ˜€
l
Yeah I might hold off on adding features until I get the basics working ๐Ÿ˜
b
You're smarter than I am. Copy -> Paste -> Struggle -> copy some more -> success
โž• 1
๐Ÿ™ˆ 2
l
My other question actually, is how does pants identify files that have changed? So far I think the plugin will work best if I hand off building the docs to jupyter book, rather than having source targets for each page, because of the interdependencies between pages (cross references and links). But so in my target I have a directory field that tells the plugin where to find the docs, but if I update one of the files, pants doesn't notice.
b
How are you measuring that pants doesn't notice?
l
I update the table of contents file, for example, run the plugin, but no updates to the pages where there should be a new page added. Then run the same thing with
--no-local-cache
and it works correctly
b
How are you feeding the files to Pants? PathGlobs?
l
yes
b
And the table of contents file is part of that glob?
l
yup
f"{directory_path}/**"
b
Try doing that without the daemon. So use --no-pantsd
l
running the command you mean?
b
Yup
Sometimes the daemon is slow to be notified about file changes. So wanna rule that out
l
yeah still not working with that flag
but with
--no-local-cache
it does work
b
Oh yikes ๐Ÿคจ
l
sort of... it causes some weird behaviour like not rebuilding all pages...
I'll try taking a look at the sandboxes to see what's coming in
b
Yeah let us know what you find
l
ahhh it's not a pants issue. It's a browser caching issue.
The browser was caching the old version of the file. So because I was clicking links to the pages it seemed to just be reloading the page from a cache, rather than the new version. Once I reloaded the browser, things came out correctly.
Ok, so that's all good. On to the sphinx plugins. Then the jb plugin will be ready to test.
๐Ÿ’ƒ 2
b
Caches on caches
b
I'm excited by how close this is! Can't wait to see.
Re the browser caching issue, is it possible to have some kind of random string injected generated, so that browsers do the right thing and don't confuse end users in the same way that you got misled?
l
I don't think it'll be an issue in production, unless someone reloads the page seconds after you've deployed a change. I think it was happening because I was on the docs page, redeployed the site, then clicked on a link. The browser loaded the cached version of the old site. But as soon as I refreshed, then it was fine.
I'm sure if you aren't in that very specific situation then it won't be an issue.
b
Terrific!
Hey, how's this going by the way? I'm excited about the prospect of being able to try this out soon. <fingers crossed<
l
So I have a working version, but went back to the drawing board on how the targets work. Instead of all docs being in one folder and just running that I want it to be able to pick up targets from anywhere in the repo. That said, work is really busy right now, so I might try to come up with a way to ship it as is so long as it won't require breaking changes in the future.
That's the question though. Would the expectation be that all docs would be built from one folder? Or is it better to be able to bring in docs from across the repo using targets?
b
@ancient-vegetable-10556 do you have thoughts on that?
a
Hrrrrr. I think for Pants, we have docs out-of-line with the rest of the codebase, because our docs are primarily prosaic (rather than reference)
and weโ€™d want to keep that
l
Yeah so you'd want a docs target for example and then chapter targets that aggregate a bunch of docs into pages/chapters. It's harder to implement obviously but I think fits with the pants model of doing things too.
a
probably. Iโ€™d need to spend some time looking a bit more closely at the proposal
l
Feedback is appreciated since I'm still learning how to do thinks in pants-world.
b
No feedback. Just enjoying that last sentence. ๐Ÿ™‚
๐Ÿ˜† 1