Alexey Stukalov

> If you would be interessted into making a separate PR for just the optional dependency stuff, I'd be happy to provide quick feedback to get that part merged and...

v0.7 CI is fine (after fixing travis), v1.0 fails because of MAT.jl

Thanks, it really looks like we can remove `with_accept()` altogether. But the check for `DATADEPS_DISABLE_DOWNLOAD` (if it's needed) still have to be moved to `download_dep()` or even to the `DataDeps`...

> Understandibly, its not terribly clear right now. Sorry about that. No problem at all. What's the difference in the MLDatasets and DataDeps behaviours?

> Basically I want to preserve to current behaviour of the download logic here. You mean `DATADEPS_DISABLE_DOWNLOAD` should only be checked by `datafile()`, while `download_deps()` should ignore this var? Now...

> What you can do in your case is just set the environment variable "DATADEPS_ALWAY_ACCEPT" to "true". Thanks. Probably it will work, I'm just not comfortable that instead of directly...

I have some minimal solution to this, by it still involves moving+extending `Enumerable` abstract type definitions from `QueryOperators.jl` to `TableTraits.jl` and using them from `IterableTables.jl`. So it's pretty invasive. I...

Ah, I guess it would be fixed by davidanthoff/QueryOperators.jl#2

It would be nice to address #133 or have some way to control the compression from `@save`. It would also be nice to do time/filesize profiling in typical workloads, because...

Compression configuration is theoretically API-breaking. It would be nice (IWBN) to decide what to do with it before releasing 1.0. If the planned change would not break the API, it...