Use package_data to ship typeshed and xml files #5517
Conversation
Data files have caused many issues where mypy cannot find typeshed. Using package_data allows us to find typeshed relative to the mypy package itself, which avoids a lot of fragile path computation.
|
@gvanrossum Could you please review this PR? |
|
Yes, I will review it. Tomorrow at the earliest. (I am in favor of the idea.) |
mypy/build.py
Outdated
| raise RuntimeError("Broken installation: can't determine base dir") | ||
| def default_data_dir() -> str: | ||
| """Returns directory containing typeshed directory.""" | ||
| return str(pathlib.Path(__file__).parent) |
There was a problem hiding this comment.
Why not os.path.dirname(__file__)?
There was a problem hiding this comment.
Well, I have a pipe dream of eventually moving to pathlib for most things, but that probably isn't realizable, so I went ahead with using dirname.
|
@ethanhs Can you resolve the typeshed conflict? |
Done. I also used dirname, as I think its probably better, and faster anyway. |
|
FWIW this is causing problems. Apparently submodules are global, not per-branch, and now I've got some very unhappy internal integrations. |
|
I think it's a problem of my own making (though affecting other Dropboxers), I can handle it internally. |
|
It was a long time ago, but everything was working nice on my PC when using a slightly different submodule definition: It was painful enough to keep this submodule change in a separate commit: alexandrul-ci@5dc3f76 My apologies if your root cause is different. |
Data files have caused many issues where mypy cannot find typeshed.
Using package_data allows us to find typeshed relative to the mypy
package itself, which avoids a lot of fragile path computation.
Fixes #5307
Fixes #5319