Thanks to everyone here who helped with my dive into Pants. I've learned a lot, and I like the direction that Pants is going. However, for my needs (easy onboarding of readers into the book's code repo) I've decided that there are currently too many barriers to entry for the average reader and thus a high probability of discouraging them. I'm planning to use Hatch for the time being, but I will periodically check back in with Pants to see how it's progressed towards removing the barriers. I'm telling you this because the usual experience is that a customer just stops using a product and disappears, so the provider is left without this kind of essential feedback (e.g.: why customers stop using your product).

Speaking completely objectively, in a single-project pure-python repo, I too would choose hatch (or at least try it out). It isn't until the requirements of the repo outgrows hatch that tools like Pants start to really shine bright. That being said, barrier for entry shouldn't land of the Pants radar, ever. So if you have specific feedback please share it and I promise we take it seriously.

Sure, here are the basics: 1. Having to install multiple versions of Python. My co-podcaster James goes further and wants to not have to install Python at all to run Pants -- just download and go. I think he brought this up during our interview and this is somewhere on the Pants radar. 2. No support for Windows native. I know this is in process. But forcing someone to jump through the hoops of installing WSL and learning to use it (especially if they're unfamiliar with any of it esp Posix) is too big of a hurdle to ask. 3. The other things seemed tolerable because they could be made invisible by the build engineer, but I would suggest that in the bigger picture it would be ideal if a build engineer is not required, at least for projects up to a certain level of complexity.

1. This is the standalone Pants (packaged with Python) solution. I've been a happy user for a little while now: https://github.com/pantsbuild/scie-pants 3. This is the one I'm super interested in learning more about. I think not needing a build engineer is incredibly important - so this has me curious what problems you ran into that would require that level of care?

@wide-midnight-78598 there's also pants-probided python via pyenv as a great idea for zero-install Pants.

via pyenv

Ah, I don't like

pyenv

(ducks arrows)

(scie-python doesn't work for reasons outside this thread)

@bitter-ability-32190 you're talking about 0 install Pants for use with Python projects? As opposed to 0 install Pants for any other non-Python use?

Correct

Ahhh, okay. Interesting. Well, the

scie

plugin I have also downloads the python-standalones, so ... who knows

Yeah, it would be great to keep the Python to run Pants as a totally seperate concept from the Python runtimes we may or may not provide. Just like we do for jvm, go, etc.

Well let's not derail an otherwise really helpful/insightful conversation about Pants' startup costs 😌

Having studied/struggled with numerous build systems over many years, I find there's a kind of limited view that often settles in around build systems. I imagine the steps going something like this: 1. Other build systems are terrible (for reasons). It can't possibly be that hard! 2. (After making an important move forward) Look, see how easy it is now! 3. Other hard things arise, and we see a slow slide into "but it's possible to make this work despite those issues." 4. New different complexities accumulate but there's increasing resistance to admitting that maybe the fundamental shift offered by the new build system wasn't ultimately the insight about build systems that it originally seemed. 5. When users have issues, a kind of subtle defensiveness appears that suggests that the user is doing it wrong, rather than acknowledging that there are flaws in the model. I completely acknowledge that this is a Ph.D.-level research problem. Every build system I've seen has run into its own limitations. But defending the design rather than acknowledging those limitations is going to prevent improvement while alienating new users, and also boosting the need for a build engineer. I think it's easy to get into a place where it's hard to see these issues creep in. It often moves out of the realm of technology and into the world of nonviolent communication, which has its own, significant, learning curve that is quite a detour from the tech world, and thus can be seen as too much effort away from tech.

As far as I can tell those style issues are all hidden in your original list item 3 above (build engineer). 1 in your original list is solved already with scie-pants, but unfortunately not 2 in your original list (Windows native support), more work to do. What items in category 3 were bumps for you @rich-kite-32423? IIRC one was just not knowing pytest, not really a Pants problem, but others were Pants problems, like source roots and the peculiarity of targets.

Well, pytest was definitely a problem because it is perfectly reasonable and even encouraged by the Pytest documentation to do something that I was told here was "bucking convention" when I tried to do it with Pants. Doing this exposed significant awkwardness in the way Pants did things, but instead of simply admitting that this is awkward, here's how you get around it, it's not great but that's how it works -- I was told that I was doing it wrong, or as above, "I don't know pytest." That's the kind of defensiveness that is off-putting. I don't necessarily expect you to rearchitect Pants to make it work seamlessly with pytest, but blaming the user for doing something that is virtually encouraged by Pytest is not going to win converts. The second experience was trying to understand the meaning of BUILD files, which really look like scripts of function calls. However, special terminology is used and the documentation is built around these ideas that strongly feel like "expert only" areas. Suggestions that maybe this approach might benefit from rethinking got pushback. If the response to issues is going to be that the user is doing it wrong and the system is fine, the system cannot improve.

Ok, all good to know. The not knowing pytest part I refer to was not knowing its naming conventions, not the non-standard way you wanted to use it, which - as you say, Pants makes awkward.

Oh. My impression from the BUILD conversation was that we DO need to rethink the docs on target v function and arg v field to help bridge the gap. I agree it's confusing when viewed without Pants goggles

In Bruce's case, even needing to use BUILD files at all is confusing.