Hey @enough-analyst-54434, thoughts on how much work it would be for Pants to start shading tools like Pytest by using Pex's current functionality? I've been looking into the alternative of mixing in tools like Pytest into user requirements—the Poetry/Pipenv approach—and not liking the coupling.

Is this still a theoretical issue or a real issue?

Let me get back to you later today..maybe I'm making this more of an issue than it actually is. I'll experiment more with things

If there are 0 reports of errors then it's a non-issue.

This is probably bigger and more complicated than you expect, and I'd rather not go down that path right now, since as John says, we have no reports of it being an issue in practice.

Okay, thanks everyone. @witty-crayon-22786 also explained to me on our 1:1 why he agrees we don't need to tie shading into lockfiles at all, and it makes more sense But one thing I'm still confused by. I just hooked up lockfiles to IPython, and the IPython lockfile uses

setuptools==57.4.0

whereas user lockfile uses

setuptools==56.2.0

. I'm confused why that collision is not blowing up when used w/

--pex-path

?

in most cases when you add directly to sys.path, no version/constraint checking is applied: things are just looked up on the path in a particular order

Interesting. Would it make sense for us to do something like ensure the user requirements come ahead of the tool requirements? I don't think we could really anticipate which order is preferable fwict

there are APIs for expanding the sys.path that do constraints checking… for example,

from pkg_resources import WorkingSet

, which the plugin resolver currently uses

Okay, after our 1:1 today + John's advice, I'm convinced enough that lockfiles make this no worse than what we had before Thanks for talking this through, folks. I will gladly not expand the scope of this project 😄