ropensci / tidyhydat

An R package to import Water Survey of Canada hydrometric data and make it tidy
https://docs.ropensci.org/tidyhydat
Apache License 2.0
70 stars 19 forks source link

download_hydat() fails if download directory does not already exist #187

Closed gdelaplante closed 1 year ago

gdelaplante commented 1 year ago

When running download_hydat() on a system for the first time, the directory C:\Users\username\AppData\Local\tidyhydat\tidyhydat is not created. Creating the directory manually allows the function to run to successful completion.

There is currently no code creating the directory (oops, my fault!). I will fix the issue and make a pull request.

At the same time I should get to creating a test file for this function.

boshek commented 1 year ago

which version are you using?

gdelaplante commented 1 year ago

0.5.7.

I assumed that file.rename (line 122 of download.R) would create hydat_path if it didn't exist, but this seems incorrect. I just made a pull request with a line (47) creating the directory if need be. I can't run it in R right now due to SSL certificate issues with our work firewall, but it's just a simple line.

fourturn commented 1 year ago

I am running into this issue as well however, I am a mac user and I am wondering how setting up this directory on mac might be different. I’ve created a few pathways and none seem to be working.

boshek commented 1 year ago

@fourturn Hi! Try installing remotes::install_github("ropensci/tidyhydat") to see if that fixes your problem. I do need to do a CRAN release. If this does fix this for you, can you please let me know?

thanks for reporting.

fourturn commented 1 year ago

Yes that appears to have done the trick. Thanks for the assistance

popovs commented 1 year ago

Unfortunately this doesn't work when working with a renv environment. I tried changing the default path when playing around with this e.g.

> download_hydat(dl_hydat_here = "renv/local/hydat") 
> hy_set_default_db(hydat_path = "renv/local/hydat/Hydat.sqlite3")
> hy_downloaded_db() # Check it's in renv path
[1] "renv/local/hydat/Hydat.sqlite3"

This worked initially, but as soon as I closed my session and restarted the next day:

> library(tidyhydat)
✖ tidyhydat requires HYDAT which has not yet been downloaded. Run download_hydat() now.

## Running download_hydat() within a renv environment fails to create ~/Library/Application Support/tidyhydat directory

> hy_downloaded_db()
[1] "/Users/sarahpopov/Library/Application Support/tidyhydat/Hydat.sqlite3" # it wasn't actually here - no ~/Library/Application Support/tidyhydat directory

> hy_set_default_db(hydat_path = "renv/local/hydat/Hydat.sqlite3") # The file is still in this directory where I downloaded it last night
> hy_downloaded_db() # But changing the path hasn't changed tidyhydat's mind
[1] "/Users/sarahpopov/Library/Application Support/tidyhydat/Hydat.sqlite3"

> hy_test_db() # for comparison
[1] "/Users/sarahpopov/Documents/ECCC/Drever contract/renv/library/R-4.1/x86_64-apple-darwin17.0/tidyhydat/test_db/tinyhydat.sqlite3"

Only after running renv::deactivate() was the ~/Library/Application Support/tidyhydat directory was successfully created and the tidyhydat database was successfully downloaded to that location.

Session info

> sessionInfo()
R version 4.1.2 (2021-11-01)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS Catalina 10.15.7

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices datasets  utils     methods   base     

other attached packages:
[1] tidyhydat_0.5.7       rclimateca_1.0.4.9000

loaded via a namespace (and not attached):
 [1] tidyselect_1.1.2  remotes_2.4.2     purrr_0.3.4      
 [4] vctrs_0.4.1       generics_0.1.2    miniUI_0.1.1.1   
 [7] usethis_2.1.6     htmltools_0.5.3   utf8_1.2.2       
[10] blob_1.2.2        rlang_1.0.6       pkgbuild_1.3.1   
[13] urlchecker_1.0.1  later_1.3.0       pillar_1.7.0     
[16] glue_1.6.2        DBI_1.1.3         rappdirs_0.3.3   
[19] bit64_4.0.5       sessioninfo_1.2.2 lifecycle_1.0.1  
[22] stringr_1.4.0     devtools_2.4.5    htmlwidgets_1.5.4
[25] memoise_2.0.1     callr_3.7.3       tzdb_0.2.0       
[28] fastmap_1.1.0     httpuv_1.6.6      ps_1.7.2         
[31] fansi_1.0.3       Rcpp_1.0.8.3      xtable_1.8-4     
[34] readr_2.1.3       renv_0.14.0       promises_1.2.0.1 
[37] cachem_1.0.6      pkgload_1.3.2     mime_0.12        
[40] fs_1.5.2          bit_4.0.4         hms_1.1.1        
[43] digest_0.6.30     stringi_1.7.6     processx_3.8.0   
[46] dplyr_1.0.9       shiny_1.7.3       cli_3.3.0        
[49] tools_4.1.2       magrittr_2.0.3    RSQLite_2.2.8    
[52] tibble_3.1.7      profvis_0.3.7     crayon_1.5.1     
[55] pkgconfig_2.0.3   ellipsis_0.3.2    prettyunits_1.1.1
[58] lubridate_1.8.0   assertthat_0.2.1  rstudioapi_0.14  
[61] R6_2.5.1          compiler_4.1.2   
boshek commented 1 year ago

Thanks for reporting - Can you confirm that you have tried this with the GitHub version?

Additionally can you share all the renv code that you are using to reproduce this? I suspect this is a separate issue to what was original reported. Having the renv code would be useful.

boshek commented 1 year ago

I have updated tidyhydat on CRAN to fix the original issue here. @popovs can you please open another issue if this did not solve your renv problem? Still very interested in that - just closing this particular issue for book keeping reasons.

popovs commented 1 year ago

@boshek works now! :smile: Sorry I did not get a chance to test over the weekend. I was using the most recent Github version at the time I was having the issue, but I just switched to a new branch (same renv), reinstalled the latest GitHub version (ropensci/tidyhydat@HEAD: 3cf9e56a -> 05f06f16), and started from a clean slate and it worked. File downloaded to ~Application Support/tidyhydat and I can access with no issues. I will keep playing around to see if I can reproduce my earlier error and will open a new issue if so, but it seems to be all good.