Closed srossross closed 1 year ago
Maybe you need '*test_*.py
@noorul is correct. You can also use something like **/*/test_*.py
.
Thanks, this was helpful :-) but I personally don't quite understand why in my situation I need vulture '--exclude=*env/**' .
for my venv situated at ./env - I tried --exclude=env/**
, ./env/**
, /env/**
, nothing seems to work :-)
Thanks for the report! The --exclude
patterns are matched against absolute paths. I clarified this in the help output and the README now.
Thanks for the report! The
--exclude
patterns are matched against absolute paths. I clarified this in the help output and the README now.
I'm curious about the rationale for this design decision. It seems rather counterintuitive and error-prone to me; it may lead to things like people with different usernames (and thus different home directories) getting different warnings unless the globs are carefully crafted.
@sliedes Can you provide a concrete problematic example for this, please? Which behaviour would you expect for --exclude
?
It just feels very surprising to me; normally, in my experience projects are developed so that you have some "project directory", perhaps a checked out repository, and you'd in my view want the checks to run deterministically inside it regardless of its location in the filesystem.
I have not encountered any pathological examples in practice (well, I only started looking into vulture last week), but I could imagine patterns written with less care like (borrowing from the discussion above) --exclude **/env/*
, where everything gets excluded for the poor new intern whose username happens to be "env" and home directory /home/env.
It just seems like a needless pitfall to me. :)
Thanks for the explanation! I hope that #310 will improve the situation.
The exclude argument does not appear to work the way I was expecting