Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Suppress message of new names being created in tibble() #1549

Open
phargarten2 opened this issue Jun 2, 2023 · 5 comments

Comments

@phargarten2
Copy link

phargarten2 commented Jun 2, 2023

Thanks for making this package. Would you consider passing the quiet argument from vctrs::vec_as_names() to be an argument (say .quiet in tibble::tibble()? The default quiet = FALSE is fine. At times, I would like to suppress the message of new names being created.

This addition would be more useful in the read_xlsx function of the readxl package, which converts Excel files to R tibbles. As Excel files often have messy names, the names will often need to be repaired, which would call vctrs::vec_as_names(). For Excel files that are repetitive (same column structure but different data), I would like to suppress the message of new names being created. But to change readxl, the authors first must pass the argument from a tibble() function to theirs. Other users may benefit from packages that depend on tibble to suppress these messages.

tibble::tibble(x = 1, x = 2, .name_repair = "unique")
#> New names:
#> • `x` -> `x...1`
#> • `x` -> `x...2`
#> # A tibble: 1 × 2
#>   x...1 x...2
#>   <dbl> <dbl>
#> 1     1     2
Created on 2023-06-02 with [reprex v2.0.2](https://reprex.tidyverse.org/)

What I am proposing is the option to remove this message in the tibble() function with the quiet argument (that is passed to vctrs::vec_as_names()):

#> New names:
#> • `x` -> `x...1`
#> • `x` -> `x...2`

Session Info:

#xfun::session_info("tibble")
R version 4.2.3 (2023-03-15 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19045), RStudio 2023.3.1.446

Locale:
  LC_COLLATE=English_United States.utf8 
  LC_CTYPE=English_United States.utf8   
  LC_MONETARY=English_United States.utf8
  LC_NUMERIC=C                          
  LC_TIME=English_United States.utf8    

Package version:
  cli_3.6.1       fansi_1.0.4     glue_1.6.2      graphics_4.2.3 
  grDevices_4.2.3 lifecycle_1.0.3 magrittr_2.0.3  methods_4.2.3  
  pillar_1.8.1    pkgconfig_2.0.3 rlang_1.1.0     stats_4.2.3    
  **tibble_3.2.1**    utf8_1.2.3      utils_4.2.3     vctrs_0.6.1  
@jennybc
Copy link
Member

jennybc commented Jun 2, 2023

This problem is already solved.

tidyverse/readxl#580 (comment)

Make sure you have up-to-date vctrs and use .name_repair = "unique_quiet" or .name_repair = "universal_quiet".

@phargarten2
Copy link
Author

Thank you. Duplicate of #632

@phargarten2
Copy link
Author

Yes, I see an option for the .name_repair argument. However, the documentation is buried within two packages to low-level vctrs as you have specified. Could the documentation for .name_repair in tibble functions be updated to reflect the options used in the repair argument in vctrs?

Please change the argument in the tibble functions:

.name_repair = c("check_unique", "unique", "universal", "minimal", "unique_quiet", "universal_quiet")

And then add under arguments for .names_repair,

The options "unique_quiet" and "universal_quiet" make names unique or universal but silence the messages (quiet = TRUE).

I believe that these changes would help make it easier for users to find this option.

@phargarten2
Copy link
Author

Due to discussion from r-lib/vctrs#1677 , the documentation should not be added to tibble():

Since we don't have ...[_quiet] variants that could override the hardcoded quiet value, I think it's better not to advertise the _quiet options in the function signatures. That would confusingly suggest the default is verbose when it is not.

@ramiromagno
Copy link

I use "unique_quiet" quite a lot actually :) but because it is not part of the enumeration of .name_repair it always makes me feel like I'm transgressing here... specially because I'm thinking, oh this argument must be passing through match.arg()...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants