Better names for duckplyr_df_from_csv() and duckplyr_df_from_parquet()

[hadley]

I was thinking that read_csv_lazy() and read_parquet_lazy() might more clearly convey their usage.

[hadley]

Or maybe read_csv_duckplyr() or similar.

I find the current selection of function names to be quite confusing.

[DavisVaughan]

My vote is for read_csv_duckplyr(), just "lazy" as the suffix doesn't feel quite right (too ambiguous?)

But keeping the read_csv_ as the prefix is quite nice for muscle memory with readr and autocomplete

[hannes]

we should also have some functions of output, e.g. write_parquet_duckplyr() or something like that

[hannes]

happy with read_*_duckplyr

[krlmlr]

DoD:

• Review duckdbfs API (very similar scope as these functions)
• Find names and agree
• Add deprecation warnings
• Implement with new names
• Add an argument to disable automatic materialization
• Release to CRAN

[krlmlr]

Let's go with the full lifecycle changes. We now also have the infrastructure to disable automatic materialization, this seems most useful when reading directly from a file, and will provide an incentive to use the new functions. This needs #255.

I wonder if the new functions should turn auto-mat on or off by default.

[krlmlr]

I decided to go with duckparquet(), duckcsv(), duckjson() and duckfile() . I really like how this blends into the new ducktbl() constructor, and what it looks like in the reference index: https://duckplyr.tidyverse.org/dev/reference/index.html .

That said, I can easily change to duckparquet_read() or even read_parquet_duckplyr() if needed.

[etiennebacher]

I mentioned this in Mastodon and it had some support (just in terms of likes), so I'm just putting it back here so that it's not completely lost (sorry for the duplication):

I think having read_*_duckplyr() or read_*_duckdb() would be better names. There are already many functions starting with read_ (arrow::read_csv_arrow(), readr::read_csv(), nanoparquet::read_parquet(), tidypolars::read_*_polars(), etc.) so typing read_ and then seeing all the options proposed by autocomplete would be very helpful.

IMO duckparquet() is not clear on whether it does writing or reading, and duckparquet_read() means that all the advantages of muscle memory and autocompletion mentioned above are discarded.

[krlmlr]

Thanks, Etienne, point taken.

By now I'm really convinced of the duck_ prefix, the only remaining question being if it's duck_tbl() or duck_tibble(), slightly gravitating towards the latter to leave the duck_tbl() name for accessing a table/view in a DuckDB database.

https://duckplyr.tidyverse.org/dev/reference/

On the upside, the duck_ prefix is much easier to type with 10 fingers on a QWERT keyboard than the read_ prefix. It's also consistent with the idea of having a common prefix for functions from a package. (I deliberately don't use the duck_ prefix for all functions, just for the central ones.)

[hadley]

As much as I love the duck prefix, given tidypolars::read_*_polars() and friends I do think it's worthwhile to think this through a bit more before release.