Hey I want to say thanks to you guys for helping me so much with this plugin writing process. The rules monad API is finally starting to click a bit in my brain. 🎉 I will reiterate one thing that I think could really help make this process easier: API docs from the code. I find myself going to the code and looking at the docstrings a lot, but i think an autopublishing readthedocs-style API guide would be a lot easier to navigate. There's really just too much detail to cover in the nice prose docs you have at pantsbuild.org right now, especially when you get into the finer points of what attributes a particular type has, etc, Anyways, thanks again for all the work and being a helpful and welcoming developer community!

You’re not at all wrong to call it The Monad API. Rules are indeed monadic - I think we avoided saying that because it might scare away people even more than we already do. Perhaps a small tooltip “FYI these are monads” would be helpful, though, for people familiar with the concept.

I'd leave the "monad" thing out of the docs though. That word has way too much baggage.

Okay, good feedback. Thanks

but yeah, i'm serious, this is really cool what you've guys have done, i'm glad it's starting to click for me, because i can see how i'll start developing plugins for internal use

The engine truly was a game changer for us with improving core Pants. Suddenly, adding a user request like

I want to include the result of

./pants package

in my test environment.

became extremely tractable. We couldn’t have had dreamed of that with the v1 engine

i had a colleague that wrote another docker plugin for pants 1.23 or something like that...it's much more complicated than what i wrote, and this seems a lot more powerful

.it’s much more complicated than what i wrote, and this seems a lot more powerful

And any caching + concurrency you wanted was entirely manual and up to you to verify that it was correct

this is the promise that actually drew me to the project: i want to be able to build all kinds of different things from one set of sources

What do you mean by that?

well some of it is just what you get from having a digraph build tool...you can slice out pieces of a large repo and build different things

That’s a really good point. And a couple users have asked about adding things like PyInstaller as an alternative to Pex. We’d love to see that happen, and it’s fairly trivial to add. We’re working on a couple blog posts for the upcoming 2.0.0 release, and part of our objective is to explain “why would you use a tool like Pants?” to people who have never tried a build tool. I think that could be a good reason to mention

i think a lot of organizations are in the exact place i'm at right now: you have a bunch of microservices that you may have used a cookiecutter template to make, and they mostly look alike, but now you want to start moving things to different deployment architectures like serverless options

Are your microservices in a monorepo or spread across different repos?

i can see one of the next plugins i write being a bridge to something like AWS Chalice, so i can generate infra code from all this as well

Cool, that’s something I personally want to de-emphasize, that Pants is specifically for monorepos. IMHO, I wouldn’t have recommended Pants 1.x to most smaller polyrepos before, but with dep inference cutting out 90% of the boilerplate + general v2 improvements, I now think Pants can be worth it even in smaller codebases.

maybe, but idk if the value proposition is as strong yet

Poetry has an excellent UX and excellent error messages - we definitely would like to get closer to that experience

rule graph errors lol (but i think you already know that)

Oh, yeah, the worst hah. We ourselves get confused by them and only know how to handle them from muscle memory the past few months. I think Stu has a path forward to improving them, and wants to work on it when back from paternity leave