Eliminate `ask_to_switch_to_non_default_cache_root_impl`

[hadley]

This message is annoying because it crops up randomly while you're doing something else, never at a time where you want to be messing around with cache settings. Given the content of the message, I would suggest simply using tools::R_user_dir("styler", "cache") (or equivalent in older R) without prompting.

[lorenzwalthert]

Thanks for the suggestion. Let me give a bit of context why this message even appears:

• The problem is that CRAN requires cached files to be removed after 6 days: Fix to retain on CRAN #836. {styler} does that, by removing all files in the default caching location older than 6 days from the cache .onLoad().
• if people don't want that, we gave them the option to opt out. Just set the option styler.cache_root to a non-default value.
• Since I don't think most people are aware of this mechanism (and caching longer than 6 days is what they want and it's for free in terms of disk space), we periodically prompt people to opt out of the default or confirm it. If you do nothing, {styler} continues to work as before. I.e. we don't force the user to do anything.

Using tools::R_user_dir("styler", "cache") is basically what happens already, and the directory is cleaned up to periodically to be CRAN compliant. For these reasons, I don't think we should eliminate asking the user to confirm the settings, which only happens if working interactively.

[hadley]

I'd suggest using a different cleanup mechanism on CRAN or during R CMD check so that you are in technical compliance with the CRAN policy, while delivering a positive experience for users.

You have probably set the option, so I suspect you don't appreciate quite how annoying the current random warning is.

[lorenzwalthert]

Although I don't agree with all what CRAN requires, the requirement that packages clean up their cache by default seems not completely unreasonable to me, although {styler} does not use disk space (just innodes) with its caching method. So I would not want to bypass this lightly (and it might even be against the CRAN policy).

I am not sure I understand why you oppose setting the option explicitly, given that it's quite clear from the message how to silence the info. Can you elaborate a bit more on why the barrier is so high?

Also, would it help if the message was only a oneliner (to avoid cluttering the console) pointing to instructions for resolving the issue that can be found in the documentation (e.g. help file)?

Also, this issue has not come up in over a year since the package release. It does not seem to be a major disturbance to most users.

[hadley]

It's annoying because I always get the message when I'm in the middle of something else. I don't want to drop whatever I'm in the middle of to do something that doesn't seem very important (because "the cache literally takes zero space on your disk"). A one-liner would help, but I really think you'd be better changing the design so that no user intervention was needed at all.

It would be an even higher barrier for most users, since I don't think the average R user knows how to find/edit their .Rprofile. I can almost guarantee that most people find this annoying, but can't be bothered to file an issue.

[jennybc]

I think it's interesting to think about whether a user has explicitly "installed and called" styler (so the type of user who's likely to be motivated and knowledgeable about configuring styler explicitly) vs someone whose styler usage is indirect, i.e. their usage is via some other package (e.g. usethis or reprex). I'd vote for making things quietly "just work" the way you think they should, for that latter person.

[hadley]

Ooooh, Jenny's comment made me realise something: I don't typically get these messages when I'm doing explicit styling; it's because something else has loaded styler.

Package loading is basically invisible as a package user, which makes this feel particularly random.

[lorenzwalthert]

I think speaking about use cases might indeed be a good idea.

it's because something else has loaded styler.

Can you maybe explain the use case here a bit more? When do these messages ocurr and how?

The typical use-case I had when creating the status quo was a package author who repeatedly styles the whole source code of his package and does not want to wait too long until this gets completed. 6 days is really not long and if someone has not touched his package for a week, the cache is gone. This is typically on the one end of the spectrum, where on the other, someone wants to create a quick reprex and gets this mesage and might not even know where it comes from.

So here's my proposal:

• In the short run, I am open to give more context to the message (so it's clearer when this was caused when another package used {styler}) and move the content of the message to the docs so it remains a one-liner at the console.
• Packages leveraging {styler} have more contextual information about their users and are best positioned to decide what should be shown to the user (or if they want to be CRAN incompliant on the user's machine). {styler} has now 37 recurse dependencies. If {styler} already handles the {reprex} and {usethis} usecase, it can't provide a fallback for the {styler} users and all other packages that depend on its functionality. So I suggest to withr::local_options() (if the user has not set the option already) for at least the {reprex} case and we can also expand the docs in {styler} for developers so that they are aware that handling the option explicitly might improve the user experience.
• We can collect opinions of other package maintainers where {styler} is used interactively to confirm they also see a problem with the current behavior.

[hadley]

Given that the cache doesn't take up any space on disk, I still don't understand why styler can't just handle this quietly. But you clearly believe strongly in the existing behaviour and I'm failing you to change your mind, so I'm going to leave it here and not pursue it any further.

[lorenzwalthert]

Given that the cache doesn't take up any space on disk, I still don't understand why styler can't just handle this quietly.

It is probably incompliant with the CRAN policy and probably more importantly is that innodes are also limited. I am not an expert enough to judge if the amount of files {styler} creates (one per file and one per top level expression) could ever grow as big that it would be a problem, I just know that if you run out of innodes, it can be extremely tricky to identify the root of the problem so I don't want {styler} to use tens of thousands of innodes without the user's consent. I just styled {pkgdown}, which resulted in ~1k additional files in my cache.

I will keep this in mind as we further develop {styler}, maybe I'll change my mind at some point, but first, I'd just like to make the message less disturbing for the use cases you outlined.

[hadley]

Ok, one last screenshot because it just hit me:

I have no idea why styler just chose to warn me here because I did not consciously style anything.

---

Nothing about the message suggests that it uses one inode per expression, and I guarantee that very few users will have any idea what an inode is (I only personally have a vague sense of what it means). If there's some chance of using 1000s of inodes, you should change the caching mechanism.

And in general, I'd encourage you to consider the spirit of the CRAN guidelines (i.e. don't permanently suck up a bunch of resources) not the letter of the instructions that they convey to you on submission (i.e. the 6 day limit). On today's computers, no one is going to notice or care about a couple of MBs (the size of a couple of animated gif), and since you're storing the data in the OS's cache directory, it can easily delete anyawy if space is needed.

[lorenzwalthert]

Thanks for the screenshot. I still fail to understand when these messages occur. Is it through calling {reprex}? Because it a call to {tidyselect} causes .onLoad() of {styler}, I am definitively missing something here. Can you please provide more context? I am now turning off the option to grasp a feeling for it myself also.

[hadley]

@lorenzwalthert I don't know, that's why the message is so annoying.

[lorenzwalthert]

@hadley #1063 is now merged with a shorter message (no warning anymore) as a first step to mitigate the problem.

Regarding the random occurrence: I have myself experienced random warnings in other contexts in R, but later I realised they were not completely random, but often one REPL expression delayed. This seems to be a bug not related to {styler}. Since you seem to have invoked {reprex} the line before (and set a corresponding option to style output), I guess that could be such an example. The fact that it's no longer a warning but a message could also help mitigating the randomness. Can you try it out through the dev version of {styler}?