Given that the jupyter book plugin is being considered for Pants' docs, I'm thinking it may be best if I publish it in one of my own repos, where I'm going to use it anyways, with some prebuilt docs. That way, anyone who wants to test the functionality can fork my repo and play with the plugin. I'll share the repo in the github discussion on this topic when it's ready and then get feedback there to make sure that the implementation works. Does that make sense as an approach?

That can make sense, but you're also welcome to submit it under

pants/backend/experimental

That can make sense, but you’re also welcome to submit it under

pants/backend/experimental

That will make it easier for other to try out. Also note (by looking at the other experimental backends for examples) is that it’s only the

register.py

file that needs to live under the experimental name.. as that is what decides what the backend name is used to register it with in the configuration. 😉 (makes it easier when the time comes to graduate out of experimental..)

ok. I'm happy to do it either way. I'll post a link to my repo as well if anyone wants to test the functionality without actually initializing a jupyter-book docs folder and boilerplate.

We can start with it outside the repo if you like, in the interest of kicking the tires on it without going through rigorous code review (but that code review would have to happen when moving it into the pants repo)

Yea exactly. I've documented my thoughts in a discussion post but that's mostly theory to everyone but me. I want to see what breaks when others try to do something basic and also see if the mvp that I have so far will work or if other changes are necessary. Doing it in my repo let's people kick the tires without setting anything up. It's really for those who might care about the functionality on top of just using it in their own repo. Because there is at least one design decision that needs to be made ahead of time that'll lead to breaking changes if we take a different approach.