https://pantsbuild.org/ logo
Join Slack
Powered by
I have a packge, i.e. `core` in a monorepo. And th...
# general
h
I have a packge, i.e. 
core
in a monorepo. And then a ton of other packages depend on 
core
. Right now, any change in core triggers a test rerun of every package that depends on 
core
. Is there a way to make this a little more fine-grained? i.e. A change in 
core.module1
triggers a test run on any package that uses 
core.module1
? Or is that not possible right now?
h
It should be fine-grained, assuming you're relying on dep inference. Do you have explicit deps on 
core
?
h
Any package that relies on 
core
lists it as a dependency in their pyproject.toml, if that's what you mean šŸ¤” Or do have to edit BUILD files with more granular deps?
Sorry to ping again, but by explicit deps, you meant stuff like the pyproject.toml, or something specific in the BUILD files of each package the relies on core?
g
@hallowed-artist-8187 my understanding (I've been using pants for a week so take what I'm saying with a grain of salt) is that if you are using dep inference (you haven't specified dependencies in any of the BUILD files). then it will be smart enough by using the import statements to infer actual dependencies, but if you explicitly add a dependency to core (the top level target), then it won't be smart and it will trigger based on any change.
šŸ‘€ 1
So I think @happy-kitchen-89482 meant is did you add anything to the dependencies in any of the BUILD files.
āœ… 1
h
ah ok, that lines up with what I'm seeing then? I did not do anything special with deps in the BUILD files beyond what 
tailor
does -- I have 400+ packages that rely on core šŸ˜“ (thanks for the input on this!!)
g
I'm hoping dep inference is smart enough that if other_module.file_a.py imports core.module_b that changes to the file with that import only trigger when core.module_b changes, not just anything in core.
h
It seems to be doing the latter šŸ˜…
g
ehh... that's not ideal.
@hallowed-artist-8187 are you using 
--changed-since
?
h
Yup!
g
Have you tried running this?:
Copy code
pants dependencies llama-index-integrations/llms/llama-index-llms-openai::
I'm curious what pants sees as the dependencies
h
good point, lets see
Copy code
llama-index-core/llama_index/core/base/llms/base.py
llama-index-core/llama_index/core/base/llms/generic_utils.py
llama-index-core/llama_index/core/base/llms/types.py
llama-index-core/llama_index/core/bridge/pydantic.py
llama-index-core/llama_index/core/callbacks/__init__.py
llama-index-core/llama_index/core/constants.py
llama-index-core/llama_index/core/llms/callbacks.py
llama-index-core/llama_index/core/llms/llm.py
llama-index-core/llama_index/core/types.py
llama-index-integrations/llms/llama-index-llms-azure-openai:poetry#httpx
llama-index-integrations/llms/llama-index-llms-openai/llama_index/llms/openai/__init__.py
llama-index-integrations/llms/llama-index-llms-openai/llama_index/llms/openai/base.py
llama-index-integrations/llms/llama-index-llms-openai/llama_index/llms/openai/utils.py
llama-index-integrations/llms/llama-index-llms-openai/pyproject.toml:poetry
llama-index-integrations/llms/llama-index-llms-openai/tests/test_llms_openai.py
llama-index-integrations/llms/llama-index-llms-openai/tests/test_openai.py
llama-index-integrations/llms/llama-index-llms-openai/tests/test_openai_utils.py
llama-index-integrations/llms/llama-index-llms-openai:poetry#black
llama-index-integrations/llms/llama-index-llms-openai:poetry#codespell
llama-index-integrations/llms/llama-index-llms-openai:poetry#ipython
llama-index-integrations/llms/llama-index-llms-openai:poetry#jupyter
llama-index-integrations/llms/llama-index-llms-openai:poetry#llama-index-core
llama-index-integrations/llms/llama-index-llms-openai:poetry#mypy
llama-index-integrations/llms/llama-index-llms-openai:poetry#pre-commit
llama-index-integrations/llms/llama-index-llms-openai:poetry#pylint
llama-index-integrations/llms/llama-index-llms-openai:poetry#pytest
llama-index-integrations/llms/llama-index-llms-openai:poetry#pytest-mock
llama-index-integrations/llms/llama-index-llms-openai:poetry#ruff
llama-index-integrations/llms/llama-index-llms-openai:poetry#tree-sitter-languages
llama-index-integrations/llms/llama-index-llms-openai:poetry#types-Deprecated
llama-index-integrations/llms/llama-index-llms-openai:poetry#types-PyYAML
llama-index-integrations/llms/llama-index-llms-openai:poetry#types-protobuf
llama-index-integrations/llms/llama-index-llms-openai:poetry#types-redis
llama-index-integrations/llms/llama-index-llms-openai:poetry#types-requests
llama-index-integrations/llms/llama-index-llms-openai:poetry#types-setuptools
Seems about right šŸ‘€ Only very select dependencies in core
šŸ‘ 1
g
My expectation is that if you changed a file in core that wasn't one of the ones listed, it shouldn't kick off tests for that sub package. I have that expectation naively, not because I know it to be true.
h
Yea thats fair, that was my expectation as well lol For example, a tiny change in 
core
https://github.com/run-llama/llama_index/pull/11376 Triggered all tests, taking ~35mins https://github.com/run-llama/llama_index/actions/runs/8040723391/job/21959154238
h
Yes, my question was whether you added any explicit coarse-grained deps in BUILD files. If not then dep inference should do the correct, fine-grained things
šŸ‘€ 1
@gentle-flower-25372ā€™s expectation is correct
if that isn't what's happening then something is going on
If you modify file A and it triggers a rebuild of B when you don't think it should have, then the first step is to use 
pants dependencies --transitive
to see if there is an unexpected dependency path from B to A.
The 
--transitive
part is important, your example above was only looking at direct deps
šŸ‘€ 1
But actually a better way is 
pants paths
(see 
pants paths --help
for how to use)
That will find a dep path between two given files, if one exists
and can help you debug this sort of thing
šŸ‘€ 2
h
Hmm 
pants dependencies --transitive llama-index-integrations/agent/llama-index-agent-openai::
This does end up listing most of core... somehow šŸ˜… I also tried 
pants paths --from=llama-index-integrations/agent/llama-index-agent-openai/llama_index/agent/openai/base.py --to=llama-index-core/::
-- I'm guessing from the help text, this is printing dependencies from each file in core to the base.py file šŸ¤” But thats a lot of (mostly repeated) outputs
g
@hallowed-artist-8187 the output (as far as I understand) is showing you the path from a to z. In other words, if you see:
Copy code
[
  "thing/a.py",
  "other_thing/b.py",
  "that/c.py"
]
That list is saying that a.py imports b.py which imports c.py. It's giving you a literal path from a->z. So I think you'd want to work backwards, i.e. let's say that you're seeing that something depend on core.unexpected_module, I would look at what is above that line and take a look at that file. I keep forgetting this is public. I am going to take a look if I have time. I'm mostly curious and following this thread trying to deepen my learning too. When you see this message let me know what specific file in core you don't expect to see.
Given that this is a transitive dependency, it actually is making more sense why it might be testing something you don't expect (at the outset). For example, if 
llama_index.agent
depends on 
core.a
and then 
core.a
depends on 
core.b
. If 
core.b
changes, that technically could impact 
llama_index.agent
. So it would make sense that any changes in 
core.b
would trigger tests in 
llama_index.agent
.
šŸ¤” 1
h
Oh yes, in case this wasn't clear, any change to the transitive dependencies of a test will invalidate that test, for the reason @gentle-flower-25372 states
2 Views
Open in Slack
PreviousNext
Powered by