|
8 | 8 | dependencies |
9 | 9 |
|
10 | 10 | why is this needed: |
11 | | -- Before we had this, a couple of browser tests appeared |
12 | | - "consistently flakier" than they were, as they were |
| 11 | +- Before we had this, a couple of browser tests appeared |
| 12 | + "consistently flakier" than they were, as they were |
13 | 13 | time-bounded by creating the jedi cache. |
14 | | -- This was taking up to a minute to get a single |
| 14 | +- This was taking up to a minute to get a single |
15 | 15 | completion value back |
16 | | -- Further, were this cache to get corrupted (perhaps due to |
| 16 | +- Further, were this cache to get corrupted (perhaps due to |
17 | 17 | killing a running test :P) things go very mysteriously bad. |
18 | 18 | - We need a way for the cache to be right before testing |
19 | 19 |
|
20 | 20 | how does it work: |
21 | 21 | - When _using_ jedi for the first time, the cache gets |
22 | | - created in `jedi.settings.cache_directory`, usually |
23 | | - somewhere in $HOME. |
24 | | -- As different libriraries are inspected by jedi, they get |
25 | | - added to the cache. |
26 | | -- This is very slow, especially on windows, and cannot |
| 22 | + created in `jedi.settings.cache_directory`, usually |
| 23 | + somewhere in $HOME. |
| 24 | +- As different libriraries are inspected by jedi, they get |
| 25 | + added to the cache. |
| 26 | +- This is very slow, especially on windows, and cannot |
27 | 27 | feasibly be cached, today. |
28 | 28 | - This script accelerates this process, so it can be done |
29 | 29 | in a controlled manner rather than during some other test |
|
0 commit comments