https://pantsbuild.org/ logo
Join Slack
Powered by
Is there a recommended way to debug why a dependen...
# general
g
Is there a recommended way to debug why a dependency can't be inferred? I even manually added the dependency to the 
BUILD
file and it's still failing to find the dependency. For context:
Copy code
[python-infer]
unowned_dependency_behavior = "error"
ambiguity_resolution = "by_source_root"
c
g
@curved-television-6568 I'm not sure which file in particular you're referring to, but I don't have either pyproject.toml or the file that depends on requests in a .gitignore. I'm also not using 
pants_ignore
.
@curved-television-6568 do 
__defaults__
apply to macros in the BUILD file itself?
Copy code
__defaults__(
    all=dict(
        resolve="my-resolve",
    )
)

docker_image(
    name="docker",
)

poetry_requirements(
    name="poetry",
)
for example, would 
poetry_requirements
inherit from those 
__defaults__
?
I tried the other side using 
pants dependents "apps/graph-relay:poetry#requests"
and that also didn't yield what I would expect.
I am using multiple resolves too if that matters.
just to be sure, I set 
pants_ignore_use_gitignore = false
and the same behavior exists.
c
> do 
__defaults__
apply to macros in the BUILD file itself? I'm not really following what you mean here. But you can easily verify this by 
pants peek some/path:docker
etc to see what value the 
resolve
field got. Having 
__defaults__
in the macro should work, but I wouldn't recommend it however, as it's effect is from the point it is declared and for all it's sub directories and can then be overridden as needed at a lower level. When placed in a macro, this mechanism is no longer in effect, as every BUILD file will have the same defaults declaration at all levels, you can no longer sensibly override it for a sub tree. If you want defaults for the entire project, simply putting a 
__defaults__
in a 
BUILD
file in the project root will do.
g
This is a fatty monorepo with 100's of pyproject.toml files all managed individually. I'm trying a bottoms up approach and creating as few resolvers as possible based on artifacts being built and their deps.
c
I'm not sure which file in particular you're referring to
Your source files. There was nothing in your question indicating it was about 3rd party dependencies. Given it's about 3rd party deps, my suggestions doesn't apply 😉 We would be able to give better assistance if you show more of what you tried, the command invoked and any output/error given.
👍 1
g
So I'm using 
__defaults__
as a means of setting the resolver for that particular project within the monorepo.
I'm all ears if there is a "better way" 🙂
c
Right, so just introduce the defaults in the "root" BUILD file for that part of the repo.
👍 1
g
so to bring things under pants I was literally generating build files (pants tailor) starting from the core thing being built and then creating a resolver for it and then using pants dependencies on the core thing being built and for all deps adding it to the resolver.
It worked for literally everything except this one thing I'm running into which is weird.
c
sounds like a good plan, to introduce it incrementally, and doing so that has as few dependencies as possible to the rest of the code base.
💯 1
g
If you want I can just show you real quick in a huddle, we can time box it to 5-10 minutes. Whatever you're willing to give.
c
sure, lets do that, I'm curious to see what issues you've got 😉
This is the rule responsible for picking up your dependencies based on analyzing imports in the source files, and a good place to start adding some logging to: https://github.com/pantsbuild/pants/blob/e430175b57d5be2b257ef17bcdecb9c22627b1fa/src/python/pants/backend/python/dependency_inference/rules.py#[…]6 (there's a global 
logger
instance, so simply 
<http://logger.info|logger.info>(...)
should do 😉 ) To try it out, clone the pantsbuild/pants repo then run pants as 
PANTS_SOURCE=path/to/pants-repo pants ...
it rebuilds as needed when you make changes in the pants repo.
🙌 1
> do 
__defaults__
apply to macros in the BUILD file itself? Ah, regarding this is terminology misunderstanding. We call them 
targets
not macros, as there is a thing called "pants prelude file" in which you can define functions, referred to as "macros". Hence my confusion. edit: https://www.pantsbuild.org/2.19/docs/writing-plugins/macros
So, to answer that question (for the record), yes they do 😉
👍 1
c
The pythondump-source-analysis goal might also be useful, it'll tell you which imports Pants found and what it thought they lead to. Guarded imports will get a "weak" status that will cause them to be ignored.
👍 1
g
I tried using python-dump-source-analysis and it essentially shows what the underlying error message is, but I still am not sure why pants isn't picking up the dep. @curved-television-6568 do you have any idea on where to put some print statements specifically?
Copy code
{
  "name": "requests",
  "reference": {
    "lineno": 4,
    "weak": false
  },
  "resolved": {
    "status": "ImportOwnerStatus.unowned",
    "address": []
  },
  "possible_resolve": [
    [
      "apps/packages/company-commons:poetry#requests@resolve=company-devops",
      "company-devops"
    ],
    [
      "utility/company-devops:poetry#requests",
      "company-devops"
    ]
  ]
}
Even if I add an explicit dependency in python_sources dependencies, it still doesn't pickup the right requests.
👀 1
The only way I can work around is to use noinfer comment and then explicitly add the dependency.
I wish I could build a repro case, but it's so complicated and it works in common cases.
c
c
looks like you've got 2 possible owners in the same resolve (possible_resolve is of type 
list[tuple[Address, ResolveName]]
). If pants can't identify the owner, it will/should emit a warning about that and then return ImportOwnerStatus.unowned. You can/should be able to use explicitly provided dependencies to get a resolution source reference
I remember there was something about the warning/error messages being cached, so if they're not appearing that might be why :$
c
Does this look like it could be the same issue you're having @gentle-flower-25372?
Copy code
08:31:14.58 [WARN] The target src/python/a/b.py imports `requests`, but Pants cannot safely infer a dependency because more than one target owns this module, so it is ambiguous which to use: ['3rdparty/python:default#requests', '3rdparty/python:test#requests'].
I just hit that, and will investigate it for my use case... (it's a single resolve, but I've split it onto two different requirements files and apparently it leaves duplicate targets for "requests" in that resolve.. although I've only listed in one of the files, and likely is a transient dep to some other req from the other file..)
@gentle-flower-25372 do you have multiple requirements.txt files in a resolve? (that seems to be broken, currently..)
Uhm... or, I've got some misconfiguration going on in my BUILD file.... 😬
yea.. nvm me, I'm a dum-dum. (I failed to properly set the 
source
field on my second 
python_requirements
target..)
g
lol. I was so excited because mine was requests! I’ll check if it’s related between multiple requirements or what. This is becoming increasingly painful.
4 Views
Open in Slack
PreviousNext
Powered by