https://pantsbuild.org/ logo
Join Slack
Powered by
hmm, is it possible that in each app module's BUIL...
# general
f
hmm, is it possible that in each app module's BUILD file in the 
example-django
repository this snippet:
Copy code
python_test_utils(
    name="test_utils",
)
is effectively dead code? at least I can't find anywhere something like this:
Copy code
python_test_utils(
  name="test_utils",
  sources=["some_test_utils.py"],
)
I'm still really new so maybe I just didn't get things yet šŸ¤· https://github.com/pantsbuild/example-django
e
So, search for the target: https://www.pantsbuild.org/docs/reference-python_test_utils#codesourcescode then the harder step is looking at that 
sources
field I linked to, but read the default value.
~All targets have a default sources glob set; so often you don't need to spell it out. Targets in fact are legacy and you shouldn't even need to write even 
python_test_utils(name="test_utils")
down in a BUILD file at all, but unfortunately you do, perhaps leading to more confusion than necessary.
IOW, I'm guessing the target in your example has a sibling conftest.py file. That is the typical case anyway.
You should really start exploring the pants metadata goals. Try 
pants filedeps <target>
for example.
f
ehm so a 
*.pyi
file ... is this a typo or something new to me?
Copy code
default: ('conftest.py', 'test_*.pyi', '*_test.pyi', 'tests.pyi')
e
New to you, but real.
Type defintiions.
f
real with an 
i
??
e
Yes.
f
complex numbers won't like that! šŸ˜„
e
Welcome to mypy and Python typechecking / "compilation".
f
ok, that sounds a little scary but whatever
e
I hope you're not too scared, Pants itself uses this extensively in its own Python code.
f
nah, just kidding. quite the opposite.
triggers curiousity
hardest problem is now to copy and paste the documentation into chatgpt to bring her/him/it up-to-date šŸ˜„
kidding again ... just to be sure
e
I like to think of myself as a physicist; so the realest things are complex numbers. Perhaps that's why your jokes aren't landing.
f
So even though targets are legacy I still need them at least in current stable release, right?
e
You still need them likely for all Pants 2.x releases unfortunately.
f
Ok, good to know
e
Killing them should have happened in the 1 -> 2 transition but didn't; so it probably waits for 2 -> 3.
f
Because inference will be good enough then or howā€™s that related?
e
Basically, yeah.
f
Not sure if inference is the right term
e
Only write metadata to guide Pants when it needs guidance.
Right now, you have to have 
pants tailor
generate throw-away BUILD files like the one you pointed out.
Except they're not throwaway, but only for legacy reasons really.
f
sounds cool
FYI ChatGPT's response about the default values šŸ˜† šŸ¤Æ
Copy code
Ah, gotcha. It looks like Pantsbuild has evolved a bit since my last update. The python_test_utils target generator seems more flexible now, and it appears to have a default for the sources field set to common test utility filenames like conftest.py, test_*.pyi, etc.

Key Takeaways:
Flexible Source Defaults: The sources field has a default value set to include commonly used test utility filenames.
Overrides: You can override specific settings for individual source files that this target generates.
Linting and Type Checking: You can skip various linting and type checking processes per target, providing a lot of control over your code quality checks.
Looks like it's a more robust and feature-rich utility than I initially thought. The lack of explicit sources in your BUILD files now makes sense; Pants is inferring them based on the defaults.
e
The pandering is nauseating.
f
that exceeds my english skills or I just don't know it šŸ˜„
ok, so because of 
python_test_utils
in the BUILD file, pants loads the conftest.py file for each test - when it's relevant? so each app module has its own conftest.py because of this? ... would this mean that by default pants disables the default behaviour of pytest to load a conftest.py file and with above it's enabled again or is pytest itself not affected by this?
e
Correct. And the secret here is that Pants doesn't run code in your repo (except for the 
pants run
goal). It copies all needed files and only the needed files over to a sandbox directory and runs there.
And, today, it only knows about files "owned" by a BUILD file and is blind to the rest in most cases.
This is the legacy bit that is unfortunate but true.
f
At least it doesnā€™t seem super intuitiveā€¦ the gains are still worth it I guess but youā€™re not getting things for free šŸ˜…
e
If you used Pants v1 or Bazel or Buck, it seems free in comparision. If you haven't it's more than a bit strange and inexplicable.
f
Is this part of the rust core somehow? i still wonder which part is doing whatā€¦
Nope, only heard of Bazel but never even tried it
e
If you're actually ciurious about that for real, you'll need to invest time reading code. If you're just lazy curious you should move on to other things.
f
Wellā€¦ Iā€™m not really an Rust developer but Iā€™ve had a couple tries so far. And and Iā€™m probably also curious to figure out how senior of an Python dev I am ā€¦ So Iā€™d give it a try - what would be a maybe easy entrypoint?
e
I'll let others help you with that.
f
Most probably though with stuff like mypy and what itā€™s doing, Iā€™d expect this above my skills
e
I'm not a fan of lazy curiosity - dig in!
f
Yeah youā€™re right. Got me! šŸ˜‚
lazy curiosity sounds a little too hard to me thoughā€¦ I get the point and essentially I agree 100% But our conversation so far helped me a lot, so thereā€™s some kind of kickstarting of new people to a project possible, right?
Are you a contributor?
h
... would this mean that by default pants disables the default behaviour of pytest to load a conftest.py file and with above it's enabled again or is pytest itself not affected by this?
This is about which files get placed in the sandbox. Currently due to the legacy behavior, those files have to be wrapped by these BUILD file targets, even if they are trivial. Pytest will always try and load conftest.py, but it won't find it unless Pants places it in the sandbox, which it requires this BUILD file stanza to do.
This is a good place to start digging in: https://www.pantsbuild.org/docs/development
f
Aahh ok this way around
h
And then looking at https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/python/goals/pytest_runner.py to see how all that is used specifically to run pytest
šŸ‘ 1
f
Ok Iā€™ll check it thx. So are you ā€œthe otherā€ who helps which John was referring? :)
So far Iā€™ve discovered that pants uses LMDB (not sure though if I had heard the name LMDB already at some point, probably not)
h
John focuses on pex work, although he's had massive contributions to Pants over the years. I am one of the current maintainers, yes.
Yes, LMDB is part of the local cache implementation
f
pex feels also like a huge improvement regarding deployment ā€¦ Iā€™m not yet at this stage but for sure docker build cache is potentially used much better
But Iā€™ll need to get one django service running to showcase the time savings ā€¦ then I hope I can eventually make a monorepo happen šŸ’ŖšŸ»
h
Open in Slack
PreviousNext
Powered by