Several times, I faced a situation when some of my...
# general
n
Several times, I faced a situation when some of my 3rd party dependencies are missing some dependency 🙂 For instance... My code imports package A, which imports package B, but B is not in requirements.txt/setup.py of package A. To solve this, I have to explicitly add a dependency on B to my BUILD files everywhere where A is imported in my code. Is there a way how can I add B as a dependency of A in one place? It would make more sense and would be better manageable in my opinion than trying to fix this in individual BUILD files. Of course, I'm always reporting these issues, but for some packages, it may take ages to solve them.
1
Another (currently possible) approach is to add
import B  # noqa
to source files with
import A
and let the dependency inference do its job, but that is also a kind of workaround. A centralized solution would be much better 🙂
e
You should be able to use a
python_requirement_library
target for this: https://www.pantsbuild.org/docs/reference-python_requirement_library Like:
Copy code
python_requirement_library(
  name="a-fixed",
  requirements=["a", "b"]
)
If you already have a version of
b
other code depends on and you want to keep that consistent, then use:
Copy code
python_requirement_library(
  name="a-fixed",
  requirements=["a"],
  dependencies=[":b"],
)
h
Hey Zdeněk, how are you defining these requirements currently?
requirements.txt
? If so, I'm thinking we should improve the
python_requirements
macro to let you make this type of association directly. Something like this:
Copy code
python_requirements(
   overrides={"Django": {"dependencies": [":setuptools"]}}
)
n
Currently, there is a
requirements.txt
file and I'm relying on dependency inference. Only in a few exceptional cases, I have dependency specified in a
BUILD
file. The approach suggested by @enough-analyst-54434 seems good, but if I understand it correctly, it would be necessary to specify dependency on "a-fixed" everywhere. The (possible) approach suggested by @hundreds-father-404 would let me continue relying on inference, right?
If anyone wants to take a look, the repo is here: https://github.com/robofit/arcor2. There is a 3rdparty folder with requirements.txt and here is one example how I cope with missing dependencies https://github.com/robofit/arcor2/blob/08d08b4ed7db9ca4cb4666267ddb0fe828810ab2/src/python/arcor2_mocks/tests/BUILD#L6 and here is the other approach: https://github.com/robofit/arcor2/blob/08d08b4ed7db9ca4cb4666267ddb0fe828810ab2/src/python/arcor2/flask.py#L5
h
So John's approach would still work with dependency inference, so long as you removed the requirement from
requirements.txt
and only had the BUILD file version. Otherwise you'd have two targets describing the same 3rdparty dep, so dependency inference would be ambiguous Pants doesn't care whether you define the requirement in
requirements.txt
vs a BUILD file vs Poetry. But, I imagine that might be annoying to have to remove it from
requirements.txt
Hence my feature idea for
overrides
, so you can change the metadata without this awkward dance. It's not yet implemented, but I really want to get to it soon
👍 1