In reality, we only want to model this as a `rest_framework.response.Response`, since our .qll modeling is more precise for rest-framework responses than if we also modeled it as a basic django http response. (specifically, that default mime-type handling is way different).
Although it might be hidden by github UI by default, it could be
interesting for a reviewer to notice the effect changes in the modeling
query has to the results in this file.
Verified by joining all files, splitting again, and observing no diff in
git.
(these operations only take a few seconds on my local machine, so
shouldn't be too much of an issue)
mostly removing of nodes from the graph.
One result lost:
```
check("submodule.submodule_attr", submodule.submodule_attr, "submodule_attr", globals()) #$ MISSING:prints=submodule_attr
```
This reverts commit 62910f0cab525ca4d4901c4c27f6e6b22c3375fc.
This reverts commit 75a8197879ec47094d9b18f3dab7bcc1c1cdba28.
We don't find `kombu.serialization.pickle_load` since we respect
`__all__`. I think that was an attempt to not flood the captured
modeling with useless re-exports, but I think we've ended up doing that
anyway... we should consider to remove that restriction!
see 21d7df29c7/kombu/serialization.py (L29)
This reverts commit 1213e786519a11142746fd3a725c874181f3a42b.
By fixing a few bugs in the SubclassFinder + manually running Find.ql on the geonode DB from DCA, I found that the installed version of owslib had both: https://github.com/geopython/OWSLib/blob/0.27.2/owslib/etree.py
I fixed it in both predicates... I think we might still be able to remove
`newDirectAlias` -- but with it being better, it will allow us to better test if `newImportAlias` actually cover everything we need!
Due to the 'only model most specific spec' logic highlighted in previous
commit, I'm changing away from MethodView/View, and use Django view instead.
In practice this shouldn't matter at all, but for writing tests it would
have been a nice fix to only have the "same name but more specific"
logic apply when it's the same _definition_ location. We used to have
this information available, but right now we don't... so instead of
spending a lot of time rewriting the core library, I simply used a
different class :D :O :(
