In some tests, I use pytest as a library (e.g. `py...
# general
In some tests, I use pytest as a library (e.g.
./pants lint ::
fails because pytest is not available in the pylint environment. I fixed it by adding a
for pytest. But this feels weird, as pytest is the standard test runner used by Pants and because now I could end up using a different version of pytest as a library vs. as a test runner. And I have to repeat that standard requirement almost everywhere. Any better way to handle this?
we do this but it just works… are you importing pytest at the top of the file when you use it like this?
You mean it works on your side without explicitly requiring it?
we list it in requirements.txt at the root of our repo so i guess we are essentially doing the same as you
we dont have to repeat it though - it just gets inferred where its used
We do not have
in our
(and I think it's more typical to put that in something like
) nor do we have a bunch of
targets and using pytest in a test works fine.
We are on version 2.13.0 right now
Oh, sorry, I missed you were doing
./pants lint
We are doing
./pants test
We don't lint unit tests
@clean-city-64472 Your root requirements.txt essentially avoid that issue then. @high-yak-85899 Okay so you avoid the issue too. Maybe I'm too much of a perfectionist. 🤣
I'd be interested in hearing what the devs recommend. I think some linting like import sorting, line length, etc. are valuable for tests. But anything related to static analysis (be it importability or full blown type checking) has always felt like overkill to me for something we intend to run. Static analysis seems more useful for production code since you may not write tests that have 100% coverage.
That issue tracks what you're asking for