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 /Users/username/pins/local/data.txt
2 /Users/username/pins/local/mtcars
As you can see, each pin is stored inside a pins/
folder and a list of resources is tracked on a data.txt
file. The function pin()
and 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.
Since this ‘local’ board is the default, you can also 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:
pins
with GitHub in the GitHub Board article.
pins
with 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.