Commit 97f1f48
authored
Switch to ureq for our simple sync HTTP get request (#1167)
Turns out that you aren't allowed to call `reqwest::blocking::get()`
from inside `tokio::block_on()`
reqwest uses tokio internally, which means that
`reqwest::blocking::get()` tries to use tokio blocking APIs, but when
you're already inside a tokio runtime (which we are due to our top level
`tokio::block_on()`) you can't use any additional tokio blocking APIs.
It results in a full panic and a confusing message.
You can supposedly do stuff like this to push the blocking work onto an
actual blocking thread used by tokio
```
let resp = tokio::task::spawn_blocking(|| {
cache::get("dplyr")
}).await.unwrap();
```
but thats so awkward to think about, especially considering that we want
the cache to be "warm" most of the time, not requiring tokio at all.
---
Instead, I think we should switch to ureq, which is one of the other
popular but more minimal HTTP clients and is _always blocking_, which is
fine for us right now.
This still requires the tweaks to the Windows github action. ureq uses
ring under the hood (at least for now, see
algesten/ureq#1141). On ARM Windows where we
have an MSVC target of `aarch64-pc-windows-msvc`, ureq needs to compile
in a lot of C code with clang, but ends up finding the Rtools MinGW
tooling that is put on the PATH, and that causes it to fail with an
`<assert.h>` missing header error.1 parent fdebe2e commit 97f1f48
7 files changed
Lines changed: 135 additions & 390 deletions
File tree
- .github/workflows
- crates/oak_sources
- src
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
39 | 39 | | |
40 | 40 | | |
41 | 41 | | |
42 | | - | |
43 | | - | |
44 | | - | |
45 | | - | |
46 | | - | |
| 42 | + | |
| 43 | + | |
| 44 | + | |
| 45 | + | |
47 | 46 | | |
48 | 47 | | |
49 | 48 | | |
| |||
0 commit comments