And I think that to dog food the Pantssystem, it really shouldn’t be a “pain point” to keep all of this stuff in the same repo, truly showing off the monorepo support.

However, to avoid burden down all pants installs everywhere, I think that the UI stuff should be opt-in, as far as possible, and for that I’m considering introducing a dedicated resolve for the backend stuff that requires API speicific libs, so we don’t accidentally pull those into core Pants.

For that to work, the part using another resolve would also have to be it’s own

python_distribution

I think.

I’m also planning on making the frontend UI pluggable, so plugin authors can register their own components/pages in the Explorer UI. (but that’ll likely be for later…)

From https://github.com/pantsbuild/pants/pull/15695

This is the minimum amount of code required to be in core Pants for: #14348

Everything else will be loaded dynamically by plugins/backends.

and further up in this thread:

[…] keep all of this stuff in the same repo, truly showing off the monorepo support.

aligns with what you said 🙂

Working on that right now.. to make the explorer backend “with batteries included, but pluggable” was a common hype-phrase when Docker was maturing.. 😛

@bitter-ability-32190 I guess I got a bit inspired by your suggestion to help out with this, so I figure we need to have some basic feature set landed to build upon.. 😄

refactoring my POC into something more maintainable and useful.

And for the graphql stuff, I think we want a dedicated python dist, so we don’t enforce a lot of API specific deps upon vanilla Pants.

OK, progress: https://github.com/pantsbuild/pants/pull/15697