Looking for suggestions. The way the jupyter book ...
# plugins
l
Looking for suggestions. The way the jupyter book plug-in will work is that there will be part, chapter, section, and doc targets. From those I need to dynamically build a table of contents. Eg if there are parts then the chapters go in those; docs can go in chapters or sections. There's a bunch of that type of logic. It should also be easy to set up and change the order of things, like insert a chapter between two existing chapters. I'm thinking about the best way to a) represent those relationships in a way that's easy to write and understand (eg parts can only have chapters so the part target should have a chapters field) and b) do it efficiently with pants. Currently my thought is to use
SpecialCasedDependencies
for the fields. Eg for a part you would have chapter dependencies; I would recursively hydrate those dependencies, keeping the order that they're listed in the field. Build the TOC as a dictionary from that recursion. Thoughts on this approach?
b
I don't have feedback for your specifics. As a drive-by comment though, SpecialCasedDependencies might be going away sometimes this year, as we want to lean into multiple typed dependency fields. Don't know if that helps or hurts 😅
l
What do you mean by multiple types dependency fields? Would that just be subclassing
Dependencies
b
I think so. Today that's either invalid or undefined what happens, but we want to lean into it. Like having Python have a ln additional deps field for type checking (type stubs belong here), etc...
h
Re the part, chapter, section, and doc targets, do those mirror basic concepts in jupyter book?
l
@happy-kitchen-89482 sorry I missed this, but yeah. It took me a while to figure out how to put it all together but each chapter is a page on the static site. Parts allow you to subdivide chapters in the TOC. Sections let you split a page across multiple files.
Couple more ideas on how to organize it so that it'll work well in a monorepo and allow building multiple sites, api docs, etc. maybe even adding in html that was built with other tools (eg API docs). Planning to write them out as a tasklist in an issue,m to break it all down.
h
Hey @loud-laptop-89838, I wanted to check in re the Jupyer Book support, see how that is coming along and make sure it's not stuck waiting for me or anyone else to provide anything? 🙂
l
Not waiting on anyone! Work has just been crazy. Ive been hiring and transitioning work and should be able to come back to it within the next week or two!
h
Good to hear!
l
So unfortunately I can't move forward any more on this. Sorry but work is nuts and I just don't have the time I need to get it done right now. I've also had to move off of pants and take a non-monorepo approach so i can't bill the plug-in as "work product" anymore. I'll take a look at the discussion and document anything else that I've done in case someone else wants to pick it up or I can come back on the future. Just can't commit to it.
b
That's a bummer, but totally understandable. This is open source, meaning that we don't owe anyone anything, but also no one owes us. We're grateful for the time people spend on contributions, even if it ends in just a brain dump 😊 We're here if your work crosses paths again with Pants. You're not a stranger 🙂
h
Thanks for investigating this @loud-laptop-89838! Hopefully someone else will be able to pick this up and continue.