https://pantsbuild.org/ logo
Join Slack
Powered by
I think this is old, but I've spent so much time i...
# development
w
I think this is old, but I've spent so much time in pants mainline, that I don't recall seeing it. Is it normal for 
import pytest
to result in a dep inference error? Pants is supplying pytest, so that feels weird
h
I don't think that's normal? We import 
pytest
all over the place, and it's in our requirements.txt
Oh, do you mean outside of the pants repo
In that case it's expected unless you have pytest in your requirements
w
Okay, dag, was hoping that we automatically ignored stuff we provided.
Not a big deal, as I recommend people setup lockfiles for most tools anyways, but it's one of those little things I think that can be confusing for new users
h
We don't provide it
We provide it at pytest runtime via the tool lockfile, but we have no way of knowing at dep inference time that the code is only going to be run in that scenario
w
Yeah... This feels wrong
In multiple resolves, I think we need to make sure pytest is available in the same resolve as the code under test? I'm investigating this a bit, to see what I've done in the past for this problem
I'm hoping I've just messed up something
c
I think you are right that for non-trivial codebases you are going to end up with 
pytest
in both that the resolve that runs pytest, and the resolve for the code under test (so it can 
import pytest
), or use one resolve for both.
w
That's what I've landed on right now. Kinda sucks, because that means runtime and build-time could be out of sync. pytest is pretty stable, but I could see this falling over
c
Yeah I feel like there is some defaults vs best practices question. Like I think most companies (or at least me) tends towards as few resolves as possible with 
install_from_resolve
. But I don't see how that could be the default out of the box experience
h
You can have pytest in your "regular" resolve and tell the pytest subsystem to use that resolve for pytest instead of a separate one
c
Yeah that's what I do. I meant that "put pytest in your regular resolve" would be a lame mandatory onboarding step, even if it is a "better" place to end up.
w
Yeah, that's what I do too - but I prefer to keep my requirements split out by "dev" vs "in production" - pytest jumps the shark on that one
Open in Slack
PreviousNext
Powered by