I have a python package with a set of 3rd-party dependencies. For the sake of simplification, let’s call the package

my-package

and say these dependencies are

numpy

and

pandas

. I know that this package will be installed in virtual environments A and B where: • A runs ◦ python 3.8 ◦

numpy

at v1.19.2 ◦

pandas

at v1.2.4 • B runs ◦ python 3.9 ◦

numpy

at v1.21.5 ◦

pandas

at v1.4.2. How would I set this up in

pants

where: 1.

my-package

has unconstrained dependencies on

numpy

and

pandas

◦ Meaning that the

METADATA

in the package indicated unconstrained dependencies on

numpy

and

pandas

so that if the package were installed without

numpy

and

pandas

already installed, then it would install those dependencies ◦ but also such that it is not specifically a dependency on

numpy==1.19.2

and

pandas==1.2.4

or

numpy==1.21.5

and

pandas==1.4.2

where one set of dependencies would match virtual environment A, but conflict with B and the other set would match B and conflict with A 2. Unit tests run in multiple virtual environments, one with

numpy==1.19.2

and

pandas==1.2.4

, and another with`numpy==1.21.5` and

pandas==1.4.2

◦ Outside of

pants

, a tool like

tox

can handle this 3. I don’t get a million warnings that look like “[WARN] Pants cannot infer owners for the following imports in the target” 4. The python version,

numpy

version,

pandas

version in virtual environments A and B cannot change Right now, I have this working where I produce 2 packages:

my-package-A

and

my-package-B

where A has pinned dependencies on

numpy==1.19.2

and

pandas==1.2.4

and B has pinned dependencies on

numpy==1.21.5

and

pandas==1.4.2

. I run the same set of unit tests, but one target has a dependency on

my-package-A

and the other target has a dependency on

my-package-B

. It’s annoying that I have package A and B, but more importantly there is another python package that has a dependency on

my-package

. For the sake of simplification, let’s call this package

dependent-package

. The problem with

dependent-package

is that it must run on virtual environments A and B, but I cannot split this up into

dependent-package-A

and

dependent-package-B

. Right now, I have this working where I produce a 3rd package:

my-package-multi

that removes the pinned dependencies. Since the code base is separately tested as

my-package-A

and

my-package-B

, I am confident that it works in both virtual environments, but it’s annoying having a 3rd distribution. On the other hand, if I create a single

my-package

with unpinned dependencies, but then in the test duplicate those dependencies with pinned versions, then I wind up with a ton of warnings like “_[WARN] Pants cannot infer owners for the following imports in the target”_

Hi Tian. Sounds a lot like the problem I’m having too 😅 https://pantsbuild.slack.com/archives/C046T6T9U/p1692798629270189 My current workaround is using multiple resolves. That helps testing since I can test the same package with different 3rd-party dependencies by using:

resolve=parametrize("python-default", "pydantic-v1")

In your case maybe you could make another “relaxed” resolve that has less strict

numpy

and

pandas

(e.g.,

numpy>=1.19.2

) requirements and depend on it explicitly in the

python_distribution

instead of having to produce 2 different packages. Here: https://github.com/EspenAlbert/py-libs is the repo if you want to look at the code ;)

My current workaround is using multiple resolves.

Right, my workaround also involves using multiple resolves. Currently, I have 3: 1 for the pinned dependencies in virtual environment A, 1 for B, and 1 with relaxed dependencies.

In your case maybe you could make another “relaxed” resolve that has less strict

numpy

and

pandas

(e.g.,

numpy>=1.19.2

) requirements and depend on it explicitly in the

python_distribution

instead of having to produce 2 different packages.

Right, so that’s what I meant by

my-package-multi

here:

Right now, I have this working where I produce a 3rd package:

my-package-multi

that removes the pinned dependencies.

but if I follow what you’re saying, I think your suggesting that I should use

my-package-A

and

my-package-B

for testing, but only release

my-package-multi

in which case it would just be called

my-package

Hm, that could work, let me give that a shot …