WIP: Clone Project and run jedi locally on it

[keegancsmith]

@ggilmore I've been trying to just speed up test_jedi.py. It seems we do pipenv twice for jedi, effectively doubling the time it takes. I assume that is related to subprojects.

----------------------------------------------------------------------------- Captured log teardown ------------------------------------------------------------------------------
workspace.py               221 INFO     Removing project's virtual environment /Users/keegan/.local/share/virtualenvs/init_extension_module-_7tEleXj
workspace.py               224 INFO     Removing cloned project cache /Users/keegan/src/github.com/sourcegraph/python-langserver/test/python-cloned-projects-cache/github.com.davidhalter.jedi.9f61554c-a65d-4910-b921-70ef9438d47e/test/test_evaluate/init_extension_module
workspace.py               221 INFO     Removing project's virtual environment /Users/keegan/.local/share/virtualenvs/github.com.davidhalter.jedi.9f61554c-a65d--ACUveBg4
workspace.py               224 INFO     Removing cloned project cache /Users/keegan/src/github.com/sourcegraph/python-langserver/test/python-cloned-projects-cache/github.com.davidhalter.jedi.9f61554c-a65d-4910-b921-70ef9438d47e

I updated pytest to enable better log capturing.

At first I was worried that we had to shell out to pipenv for every language server interaction (ie each hover), but that seems to be incorrect. So it seems most of the slowness is in setting up and tearing down the fixture. Can I propose we add an optional "fast" mode which avoids teardown and reuses the virtualenv per fixture. I think that should make the test suite much faster.

[ggilmore]

Would it be okay if the fast mode was enabled locally, but disabled on CI?

On Fri, Mar 16, 2018, 7:12 AM Keegan Carruthers-Smith < notifications@github.com> wrote:

@ggilmore https://github.com/ggilmore I've been trying to just speed up test_jedi.py. It seems we do pipenv twice for jedi, effectively doubling the time it takes. I assume that is related to subprojects.

----------------------------------------------------------------------------- Captured log teardown ------------------------------------------------------------------------------ workspace.py 221 INFO Removing project's virtual environment /Users/keegan/.local/share/virtualenvs/init_extension_module-_7tEleXj workspace.py 224 INFO Removing cloned project cache /Users/keegan/src/github.com/sourcegraph/python-langserver/test/python-cloned-projects-cache/github.com.davidhalter.jedi.9f61554c-a65d-4910-b921-70ef9438d47e/test/test_evaluate/init_extension_module workspace.py http://github.com/sourcegraph/python-langserver/test/python-cloned-projects-cache/github.com.davidhalter.jedi.9f61554c-a65d-4910-b921-70ef9438d47e/test/test_evaluate/init_extension_moduleworkspace.py 221 INFO Removing project's virtual environment /Users/keegan/.local/share/virtualenvs/github.com.davidhalter.jedi.9f61554c-a65d--ACUveBg4 workspace.py 224 INFO Removing cloned project cache /Users/keegan/src/github.com/sourcegraph/python-langserver/test/python-cloned-projects-cache/github.com.davidhalter.jedi.9f61554c-a65d-4910-b921-70ef9438d47e

I updated pytest to enable better log capturing.

At first I was worried that we had to shell out to pipenv for every language server interaction (ie each hover), but that seems to be incorrect. So it seems most of the slowness is in setting up and tearing down the fixture. Can I propose we add an optional "fast" mode which avoids teardown and reuses the virtualenv per fixture. I think that should make the test suite much faster.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sourcegraph/python-langserver/pull/47#issuecomment-373725295, or mute the thread https://github.com/notifications/unsubscribe-auth/AImqO1DuCITx6flYA_ScawGBVBeXIUb9ks5te8g0gaJpZM4SY9nJ .

[ggilmore]

And yes, two virtual environments are created because there is a subproject in the tests for the jedi repo.

[ggilmore]

https://github.com/davidhalter/jedi/tree/270f70ea7efaea23c325f2e307305900007e9e0c/test/test_evaluate/init_extension_module

[ggilmore]

Re-subprojects:

The current strategy is just to go through the entire workspace looking for installation files - and to assume that their presence indicates that there is a subproject that starts at that folder level. We create virtual environments for each subproject.

This logic doesn't work off the bat with some simple test cases that I wrote (not sure why atm). Given that, I think that it's fine to revert b17dae21d4fca2e2b99a64bc566925daa4523ea2 if it makes things easier.

[keegancsmith]

yup, just on CI sounds good to me. FYI the CI envar var being non-empty is a mostly universal indication you are on CI.