Michael Chirico

Ah that's wonderful! Thanks!!! Solves my issue, which is narrower than that of this issue overall.

if the package is expecting some `data.table` functionality, defining `.datatable.aware

But if relying on `dtplyr`, certainly that author is aware of `data.table`, so they can signal that to `data.table` with `.datatable.aware`... what you're going for is that `dtplyr` "just works"...

Could you file a PR citing this issue adding `dtplyr` here: ``` "data.table" %chin% names(imports

That also looks doable. I would probably set `.datatable.aware=TRUE` inside the `data.table` namespace as well since we aim for that case to be handled first. I'm not sure all of...

[`fread`'s approach](https://github.com/Rdatatable/data.table/blob/master/R/fread.R#L44-L66) is to download the file & proceed to use plaid-old `fread` on that. @jennybc If you're happy with that logic, I'd be happy to file a PR.

Would appreciate if you could reproduce/summarize the part of the discussion regarding why to keep using `curl` for `https` as this might inform the choice in `data.table::fread` as well. Thanks...

Thanks for the heads up! @jennybc would you like me to patch that into the bundled copy here?

FWIW it doesn't affect us either way. we delete the bundled libxls copy & depend directly on the (patched) source library directly.

lintr is typically taking O(10 seconds) on full packages, but yes there is an expression-level caching mechanism