-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Add mypy_path config option (#2323) #2329
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Current coverage is 83.48% (diff: 47.36%)@@ master #2329 diff @@
==========================================
Files 72 72
Lines 19012 19018 +6
Methods 0 0
Messages 0 0
Branches 3931 3932 +1
==========================================
+ Hits 15873 15877 +4
- Misses 2542 2543 +1
- Partials 597 598 +1
|
I don't see the test you mentioned in the PR, so it's hard for me to say what might've gone wrong. If you add it I can take a look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of introducing a new stubs_dir concept, I'd much rather see this setting be precisely equivalent to (and superseeded by, if present) MYPYPATH
.
Updated - is this ok? As for the test, I figured it will make more sense to add a test case to |
@@ -451,6 +451,7 @@ def get_init_file(dir: str) -> Optional[str]: | |||
'python_version': lambda s: tuple(map(int, s.split('.'))), | |||
'strict_optional_whitelist': lambda s: s.split(), | |||
'custom_typing_module': str, | |||
'mypy_path': lambda s: [p.strip() for p in s.split(',')], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you split by os.pathsep
here instead of commas? That way it mirrors MYPYPATH
's behavior and is a little more idiomatic.
Also, it's a bit subtle, but I think you shouldn't strip the paths here -- that's not what happens with other paths specifiers (like $PATH
) and it makes it impossible to specify a path with a space at the end (though I'd hope no one actually wants to do that).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's better to stick to a common convention of handling lists in config files. Parsing that setting this way would probably cause confusion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the env variable that this is supposed to track uses os.pathsep (':'). So using commas here would also probably cause confusion. Maybe we can compromise and split on spaces, commas and colons?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure. At that point, this function could have a test too. How can I add a small unit test? All I can find is big test suites or use-case scenarios, and that's too much to test a pure function 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Splitting on commas and colons seems reasonable, but we shouldn't split on spaces: it's not uncommon to have spaces in directory names. It'd be nice to mention allowable path separators in the documentation for this config option.
@gvanrossum do we currently have tests for the config file somewhere?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking good! Just one more small change here. After that and the unit test, this should be ready to merge!
OK, as long as leading/trailing spaces are stripped (I think I want to be
able to write "path = x, y, z").
There are some tests for config files in cmdline.test.
|
If you rebase now the tests should pass. |
I'm up to date |
OK, I'm going to look into why the tests fail then. Because that failure seems due to a missed typeshed sync to me (you didn't touch reports.py, there was a recent change to reports.py that depended on some typeshed changes). |
Yeah, it looks like typeshed is out of date. You can fix that with |
This looks good! We should probably change |
Ok, will do - thanks for noticing that issue @ddfisher! |
I did |
Thanks! |
I tried to write a simple test for the new
build_lib_path
function, but pytest wouldn't pick it up. Help?