feat: add qs2 cache file format

[gisler]

Types of change

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Other (documentation etc)

Pull request checklist

• Add functionality
• Add tests
• Update documentation in man
• Update website documentation

---

Proposed changes

Hi there,

I recently noticed qs got deprecated and I just implemented qs2 as a replacement. And I ask myself if it is worth keeping the qs file format. I failed to compile the qs package with R v4.5.3. What do you think?

[gisler]

Hi @KentonWhite!

Did you have time to think about my question?

By the way, the code you added in 5e2e17c will never be called because of this function call:

  require.package(
    cache_format[["package"]],
    attach = config$attach_internal_libraries
  )

[KentonWhite]

Haven’t had a chance to review yet. Moving to Australia and a bit busy :)

[KentonWhite]

Thanks - this was on my list of things to do. I notice that there is no backward compatibility with qs. I don't use qs or qs2 - will switching to qs2 without a fallback to qs break for users with qs files @gisler ?

[gisler]

Oh, moving to Australia definitly sounds like effort.

Yes, removing qs would break things. But it's just a cache. So switching to qs2 should generally just recreate it. In case the cached data stem from a DB query, it might not result in exactly the same data though. Depends on if the data changed in the DB or not.

I guess it doesn't hurt to leave qs there. But shouldn't it remain in the suggested packages list then too? I'm actually surprised CRAN didn't complain.

[KentonWhite]

Yes let's do that. Keep qs available for backward compatibility but only have qs2 in the suggested packages.

[gisler]

OK @KentonWhite, all done now. I think the code is ready to merge. I have one or two more small changes, but one thing after another.

[KentonWhite]

Committed. Thanks!