Someone check me on this. I think I need a new feature (at least for

pytest

) where the resolve the requirements come from isn't static. Instead you'd set

install_from_resolve

to

true

to say "install from the resolve of the test' source. It's for cases where: • You have

test_resolve_a

in resolve A. It uses fixtures or whatever, so does

import pytest

• You also have

test_resolve_b

in resolve B. Same schtick.

import pytest

• Their ICs don't overlap So no value of

install_from_resolve

would work. Not even putting

pytest

in its own resolve (because of the imports). Instead

pytest

should come from the resolve of the source file.

You could have a resolve that supports both versions (assuming it can be generated)?

Logically, I don't think that's correct. My user code shouldn't (and can't) import

pants

.

Why would having pytest in its own resolve not work?

It would, but would also be janky. Dependency inference means

pytest

would also have to be in each of the resolves, and hopefully of the same version as the pytest resolve.

I could imagine a dynamic

install_from_resolve

being useful (although not by passing

True

, as that is a typing nightmare). It would need to be implemented generically, but I think that's fine. We should always be partitioning by resolve before we use a tool anyway.

I'm not sure it would be a typing nightmare. Unions exist 🙂

Not in the options system though

Oh right. It's doable, I think, but possible ill-advised

I very much don't want to complicate the options system any further

I hit the same use case for pylint before I left Color - there’s an existing issue floating somewhere