Python: Add example of top-level module shadowing stdlib#4655
Conversation
Although this test is added under the `wrong` folder, the current results from this CodeQL test is actually correct (compared with the Python interpreter). However, they don't match what the extractor does when invoked with `codeql database create`. I want to use this test-case as a reference, when updating the tool invocation from our testing setup to match what happens in the extractor. It would be better to just fix the extractor, but that is not trivial, since it requires us to correctly guess the root of source-code in a project (so we can simulate it becoming the first element of `sys.path`). Making the behavior of our testing setup the same as the production environment is a step in the right direction in my opinion (even if that means having the same known problems). Inspired by the debugging in github#4640
|
Converted to draft, since I don't want this merged before we decide on what order to merge extractor change and this PR in. |
|
Made internal changes to extractor that is used by |
|
🎉 |
|
Note that the tests did indeed fail after the internal extractor change was merged, but we had to revert that change since it broke a lot of our existing tests (and we didn't notice initially). Changing the way qltest invokes the extractor was a bit of a challenge, and there are more important things to do right now... so manually changing the test to do the same as |
Changing the way qltest invokes the extractor was a bit of a challenge, and there are more important things to do right now... creating an internal tracking issue for this instead.
RasmusWL
force-pushed
the
python-add-import-test-shadowing-stdlib
branch
from
7cb6641 to
62b7fdd
Compare
|
This PR has turned into a disaster. I'm closing it, to start from scratch, and will pretend it never happened. |
2 participants
Although this test is added under the
wrongfolder, the current results from this CodeQL test is actually correct (compared with the Python interpreter). However, they don't match what the extractor does when invoked withcodeql database create. I want to use this test-case as a reference, when updating the tool invocation from our testing setup to match what happens in the extractor.It would be better to just fix the extractor, but that is not trivial, since it requires us to correctly guess the root of source-code in a project (so we can simulate it becoming the first element of
sys.path). Making the behavior of our testing setup the same as the production environment is a step in the right direction in my opinion (even if that means having the same known problems).Inspired by the debugging in #4640