Initial attempts at trying out multiple resolves… ...
# development
c
Initial attempts at trying out multiple resolves… 🧵
OK, so I had an idea to create a dedicated resolve for the explorer api server distribution, so we don’t accidentally introduce new dependencies in the other parts of Pants. But I ran into this issue:
Copy code
pants.backend.python.dependency_inference.rules.UnownedDependencyError: Pants cannot infer owners for the following imports in the target src/python/pants/backend/explorer/graphql/context.py:

  * pants.engine.explorer.RequestState (line: 12)
  * <http://strawberry.types.Info|strawberry.types.Info> (line: 9)

These imports are not in the resolve used by the target (`python-explorer`), but they were present in other resolves:

  * pants.engine.explorer.RequestState: 'python-default' from src/python/pants/engine/explorer.py
So, perhaps this way of using resolves is not a good fit for my use case here..?
Reading up a bit on resolves, it states that for a python_source, all it’s dependencies must also share the same resolve. This makes it problematic here, as there are dependencies into core Pants, which I explicitly do not want to share this resolve with…
I can understand this limitation within any given distribution, but if we cross distribution boundaries, must this restriction still apply?
Or do I simply just add my dependencies to the default resolve, and trust that they won’t end up in the “vanilla” pants distribution, as there should be no code there depending on them. If so, it would be a nice feature to be able to flag certain dependencies as banned requirements for certain dists..
Going with the latter for now, to unblock myself…
b
IIUC I think the default resolve stays, but your new resolve becomes a superset
So any core python source see the requirements in the default resolve when being used by the core code, or by the new resolve when being used by the new code
f
Or you put the core files in both resolves via
resolve=paramtrize(“a”,”b”)
?
b
It's both right?
Both resolves need the "core" imports, and all the core code needs to be parameterized on both resolves.
f
Yeah both.
c
Yeah, I'd prefer not to add resolve fields all over the place if possible..
b
I'm not sure you can get away with it with the current implementation 😐
w
yea, that’s the status quo until we support applying metadata to more targets. currently you’d need to apply
resolve=paramtrize(..)
in a bunch of places (or use macros)
but i don’t think that you actually want multiple resolves here. this code will be mixed into Pants’ pythonpath, and so it needs to be fully compatible with that resolve
(all plugins are, but not all plugins have the benefit of living next to Pants’ resolve)