should i be able to run all tests with `./pants te...
# general
g
should i be able to run all tests with
./pants test ::
on pants itself after i cloned it from github main? atm some tests fail.
b
Theoretically, yeah Unfortunately that's not true today. A while back I made a push for us to skip tests that require certain system deps if not available, but didn't cover everything
g
so if i change something on the python backend, what would be the best way to guarantee i did not break something already functioning? just the pre-commit hook seems a little bit less to me?
c
there are so many and some long running tests, so I tend to only run the tests touching the area I’m working on, and rely on the GH test runs to cover the rest.
☝️ 1
b
If you wanna skip tests that fail for you, please do 🫡
g
i just thought the big idea behind pants would be things like "easier onboarding" and "ability to run all tests" ^^ but nervermind. thats clearly an pants problem not a pants problem 🙂
maybe it would help to explain a little bit more how to setup a full dev env?
👍 1
c
with remote caching enabled, that would speed things up considerably, but being a loosely composed team there’s no shared configuration for remote caching for all maintainers/contributors (and even less so for community contributions) so in theory running all tests once should give you a good local cache, that’s not really practical. 😉
b
You'll find there's two Pants' experiences. The user experience of the tool, then our own dev experience. The core issue is that parts of pants aren't completely hermetic, and so if I'm developing code that operates with go installed, I'm gonna have to installed. As is CI. So in my bubble, nothing's telling me I should skip this test if go isn't installed 😅
And we can only really expect incremental progress. We're a team of people loosely focused on features, as that's what our employers pay for. In hobby time, or secret time, we can incrementally work on these things for sanity, but there's nothing driving us towards large-scale "health". It all just happens organically
Theoretically, we could run CI on a bare-bones VM and expect it to pass. Anything that fails is a candidate for a conditional skip. If our CI didn't take so long as-is I actually think it'd be worth dojng
g
i just write my thoughts as i'm fairly new to pants and maybe i have a fresh look to some grown things :)
👍 3
b
We love fresh looks. Seriously. The eyes get old and shades get pants-tinted so it's hard to see things fresh and clearly. Please share all thoughts you have as you please 😄
☝️ 2
2
🙂 1
Consider this your "welcome aboard" speech 😅
e
I found this problem when I started working on Pex as more than a casual contributor ~4 years ago. It uses tox, I wrote a top-level dtox.sh script that runs tox, but in a Docker container with all the right stuff installed so that tests would actually all pass: + https://github.com/pantsbuild/pex/blob/main/dtox.sh + https://github.com/pantsbuild/pex/tree/main/docker In the ensuing years there are now devcontainers, which I think are basically this same idea. Ideally you wouldn't need to step outside Pants to have its own self-dev experience be smooth - and I think we're working towards that with recent environment support / local containers support for running actions - but, in the meantime, maybe this is a path to take if someone is motivated. Its dead simple.
h
This prompted me to fix up some tests that didn’t pass on macOS: https://github.com/pantsbuild/pants/pull/17410
Now
./pants test ::
should pass on all supported platforms (although there may still be a corner case or two)
e
Yeah, like you don't have docker installed or helm, or etc.
That was the point of dtox.