Use environments for Connect content + user caches

[juliasilge]

Addresses #635

Instead of removing these troublesome caches like #660 was headed for, this PR instead changes these caches over to use environments (instead of files on disk). This means that:

• caches will not persist between sessions
• caches will only get into a broken state if a big change is made with the server while a user is working with pins from R
• caches can be fixed by restarting R
• the first time functions are called they will be slow, but subsequent calls will have the same benefits of caching as we have now

[juliasilge]

I put these here? And also I think it's simplest to still have two of them, one for the pieces of content and one for the users.

[hadley]

I think this is a totally reasonable approach but we're starting to build a bit of a consensus around using the as a sentinel for a mutate package environment. If you wanted to use that, I think you'd do:

the <- rlang::new_environment()
the$content_cache <- rlang::new_environment()
the$user_cache <-  rlang::new_environment()

[juliasilge]

This idea worked out great IMO @hadley!

[hadley]

I think this is a totally reasonable approach but we're starting to build a bit of a consensus around using the as a sentinel for a mutate package environment. If you wanted to use that, I think you'd do:

the <- rlang::new_environment()
the$content_cache <- rlang::new_environment()
the$user_cache <-  rlang::new_environment()

[machow]

Just a heads up -- AFAICT one side-effect of this change is that if users restart their R sessions, they'll be unable to access cached RSC pin content without an internet connection. The issue is that already accessed content will be in their on-disk cache, but there will be no mapping back to it :/

(it might be worth letting people access pins via guid in the future to work around? see rstudio/pins-python#79)

[juliasilge]

@machow That is not different than if we turned the cache off via an environment variable or eventually removed the cache altogether, correct? Those were the other options we have been talking about.

I like the idea of using the GUID as an internal bit of metadata.

[github-actions]

This pull request has been automatically locked. If you believe you have found a related problem, please file a new issue (with a reprex: https://reprex.tidyverse.org) and link to this issue.