Whenever you run
pin(resource), the resource is stored; by default, this means storing it locally on your computer for the purposes of caching it to avoid re-downloads, recomputing, etc. We can explore this local storage by creating a pin and then enumerating the board’s storage folder:
# A tibble: 2 x 1 paths <chr> 1 /private/var/folders/ks/RtmpL6bsZy/file5d7f/temp/data.txt 2 /private/var/folders/ks/RtmpL6bsZy/file5d7f/temp/mtcars
As you can see, each pin is stored inside the temp folder and a list of resources is tracked on a
data.txt file. The function
pin_get() store and retrieve data from this well-known location, while
pin_find() makes use of the index file to search for resources and track other properties like cache expiration information.
To avoid pins being reset aftere your R session restarts, you can register and use a ‘local’ board and explicitly store or retrieve datasets from this board:
A local board is quite useful for all the reasons mentioned in the Getting Started article; however, to take full advantage of pins, you can also consider storing pins in shared locations that others can access, for instance:
pinswith GitHub in the GitHub Board article.
pinswith GitHub in the Kaggle Board article.
However, since there are many more storage locations to consider (see for instance Where should scientists store their data),
pins also supports web-accessible locations through Website Boards and even custom boards to fully-support reading, writing, authentication and so on. You can learn how to create extensions at Extending Boards.
Please be mindful when using boards, you should only register boards you trust. As a general good practice, when using GitHub, it is not advisable to clone and build R packages from GitHub repos you don’t trust. In a similar way, you should not register GitHub boards, nor Kaggle, nor RStudio Connect, nor Website boards that you don’t trust.