Add use_criteria() for customizable root-finding criteria

[Copilot]

v1.0.2 added is_quarto_project to default root-finding criteria, which breaks users with Quarto projects nested inside larger repos — here() finds the nested _quarto.yml before the repo root.

Changes

• R/criteria.R — New exported functions:
  • use_criteria() — set active criteria via character vector of names or root_criterion object
  • default_criteria() — returns default criterion names as character vector
  • Internal resolve_criteria() / names_to_criterion() for name-to-object resolution
• R/zzz.R — .onLoad() checks "here.criteria" option before falling back to defaults
• tests/testthat/helper-local.R — Fix local_here() bug: was capturing env reference (old_root <- .root_env) instead of root list (old_root <- .root_env$root), causing state leakage between test files
• tests/testthat/test-criteria.R — 15 tests including the nested Quarto scenario

Usage

# Exclude Quarto detection
use_criteria(setdiff(default_criteria(), "is_quarto_project"))

# Or set before package load (e.g. in .Rprofile)
options(here.criteria = c("is_here", "is_rstudio_project", "is_vcs_root"))

# Also accepts root_criterion objects directly
use_criteria(rprojroot::is_rstudio_project | rprojroot::is_vcs_root)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>here v1.0.2</issue_title>
<issue_description>Just a small note that here v1.0.2 adding support for detecting Quarto and other project types is probably a bigger change than is signaled with the patch release version bump.

I have a repo with a Quarto website in a subfolder. With v1.0.2, calling here::here() inside the Quarto website points to /website where elsewhere in the repo it points to the repo root.

It's not a big deal and after updating paths I feel like it's a net positive; but it did take a minute to discover.</issue_description>

Comments on the Issue (you are @copilot in this section)

@krlmlr Thanks for the heads-up! @krlmlr Thanks. For now, please use here v1.0.1 or the lower-level rprojroot package for custom criteria.

@jennybc: How do you feel about detecting Quarto projects?</comment_new>
<comment_new>@jennybc
I guess I still feel like it makes sense to detect a folder containing _quarto.yml as a project, at least by default. So are the folks weighing in here saying that they have quarto projects (folders with a _quarto.yml file) nested inside a parent folder AND they want to refer to files outside the quarto projects from inside the projects? I think we could really benefit from some concrete scenarios here. I'm struggling to "get it".

But on a more general level, it does also feel possible that here should offer a way to configure the root-finding criteria. I do something similar in gargle, but there it's about an internal registry of auth methods to try. 99% of folks accept the defaults but every now and then it truly is useful to nuke one of the methods in a specific setting. And to pre-empt one possible response: one could refer folks to a lower-level tool like rprojroot, but there's such a big gap in user-friendliness and UX between here and rprojroot that I'm not sure that's a reasonable solution.</comment_new>
<comment_new>@krlmlr
An option that allows for a character vector that defines the active criteria? Or alternatively a list of criterion objects?</comment_new>
<comment_new>@jennybc
Thanks for adding color, folks!

@wmattbrown It feels like if you just have quarto documents (Quarto files, as you say), the project root should remain as it was before (whatever folder is the parent of data, scripts, intermediate files, outputs). So you can have .qmd files below scripts/ and they can refer to things in intermediate files/. Is there some reason that you also have _quarto.yml in scripts/? I think this is what I'm not understanding.</comment_new>
<comment_new>@jennybc
My mind is elsewhere at this moment, but I feel like this discussion has been super helpful at generating much more detailed and actionable ideas. I think the recent expansion of default project root criteria is a real net win, but it's obviously caused some pain, which kinda makes sense. It totally stands to reason that growing that list basically comes with a greater need (the first need, really) to offer easier ways to explicitly customize or control here.

I would be happy to join in (or even take the lead) on implementing something based on the above soon. I've just had a very trying month of computer chaos and am getting settled back in to my newly repaired mac 😅 .</comment_new>
<comment_new>@jennybc

I actually would have expected the .here file to take precedence

Project-root-finding proceeds upwards from current working directory and stops the first time a root criterion is satisfied. So practically speaking, there's no hierarchy of criteria, i.e. where one would take precedence over another.</comment_new>

• Fixes here v1.0.2 #151

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.