very random question.. is it normal for pants v1.30 to take so long to run tests? I mean.. somewhere around 30 minutes.. keeps hanging there ->

============== test session starts ===============
platform darwin -- Python 3.7.8, pytest-5.3.5, py-1.9.0, pluggy-0.13.1
cachedir: .pants.d/test/pytest/.pytest_cache
rootdir: /Users/lzfnyy/Projects/clueless, inifile: /dev/null
plugins: cov-2.8.1, sanic-1.6.1, timeout-1.3.4

No, unless you expect your test to take a really long time. How long would you expect? It might legitimately be a hung test. You can set

timeout=120

(in seconds) to the

python_tests()

target https://www.pantsbuild.org/docs/python-test-goal#using-timeouts

it might be something off with these crazy dependencies… tensorflow and whatnot

Is it a new test? Flaky tests are the worst, we had a couple of them from the v1 engine (now removed) and they really slowed down our CI I’m wondering why this only recently might have started happening

I’m not sure, I’ll have to debug these.. I think after someone added

pandas

it started throwing a couple of odd warnings here and there.. same for Tensorflow.. I just wanted to make sure that

pants

wasnt really causing anything before diving in

Generally, never say never. There could be an issue with pants that is causing it to hang that we aren’t aware of. We don’t know of anything that would cause a hang, but certainly possible Is this in CI or locally? It might be interesting to run, say,

top

, to see if the CPU is in active use

It’s deterministic and I think it is also happening when using

pytest tests

so I’m almost sure that

pants

isnt the culprit but I’ll update you guys on this matter

Cool. I mean still frustrating, but determinism is much better. Flaky tests drive me wild. I think everyone’s different here, but I personally really like using printing/logging to identify at what point things start hanging. “How far” can you get in your code before it hangs.

hey @hundreds-father-404 I’m investigating the tests here and I was wondering if it’s possible to set the plugins inside a BUILD file instead of

pants.toml

. I have a couple of tests that are dependent of

pytest-sanic

but everything else isn’t.

You could treat the plugins like normal 3rd-party requirements to those

python_tests

targets. See https://www.pantsbuild.org/docs/python-third-party-dependencies#defining-inline-requirements for how to define those requirements inline, if you don’t want them to be in a global

requirements.txt

. Then, add the targets to the

dependencies

field. Note that dep inference won’t ever be able to infer the deps, as they aren’t used in import statements. This is how we load

pytest-django

in Toolchain’s repo

is the toolchain repo oss too?

It’s not. A lot of what we work on gets open sourced, though

haha just wanted to take a peak on your BUILD files 🤣

I can give you a sample! Almost every one of our BUILD files looks like this lol thanks to dep inference:

python_library()

python_tests(name='tests')

A more complex example

python_library()

python_tests(
  name='tests',
  dependencies = [
    '3rdparty/python:pytest-django',  # Test time requirement.
    'src/python/toolchain/buildsense',  # Used in `conftest.py`.
     ...
  ],
)

oh yeah, awesome I’ve been wanting to ask about that.. I did notice those empty

python_library()

and I have a couple but I’m not sure what they’re doing 😕

It’s telling Pants “This is Python production code here that you should know about. It uses the defaults for everything. Nothing special going on.” See https://www.pantsbuild.org/docs/targets#default-field-values

oh that’s really helpful

I was originally honestly a bit opposed to dep inference and favored buildgen, which writes to disk. And then I realized how much I like how BUILD files read now, that they’re much more declarative because 95% of the noise is removed

sorry about asking these silly questions,

Not at all silly. We made some pretty fundamental changes to how you interact with Pants in 2.0, with a) dependency inference and b) “file-level addresses” that allow you to operate with file-level precision, e.g. depend on just a file (https://www.pantsbuild.org/docs/how-to-upgrade-pants-2-0#files-are-now-the-atomic-unit-rather-than-targets-130-vs-20) It took us about 2-3 months of iterating on different designs. Definitely not silly or trivial with questions like that