Add support for imports field in standalone files

[lionel-]

This will pick up the new imports: field added in r-lib/rlang#1589 and ensure all dependencies are with sufficient versions are included in Imports.

[lionel-]

Looks like the snapshot failure is from the latest commit to main.

[jennybc]

It feels like this is moving towards what we normally accomplish with DESCRIPTION. I end up wondering if we should lean into that, so we can use existing tooling for parsing this info.

[jennybc]

I think what I'm literally suggesting is: perhaps we should use DCF for this frontmatter. That would make it easier to get the Imports info into desc and let it do the parsing, validating, etc.

[jennybc]

I'm noticing that we have a pre-existing problem with not passing along host.

Should ref propagate as well? I would think so.

[lionel-]

Now fixed.

[lionel-]

I think what I'm literally suggesting is: perhaps we should use DCF for this frontmatter. That would make it easier to get the Imports info into desc and let it do the parsing, validating, etc.

Do we have any non-internal tools for parsing versions etc? I tried to find some but my research wasn't fruitful. I was planning to use DCF like this because I initially thought the desc package would help here, it looked like this:

imports <- paste0("Imports: ", paste0(imports, collpase = ", "))
desc <- desc::desc(text = imports)

But this didn't help much because I still needed to parse the versions after a get_deps(). I think what I take from this is that the hard part isn't in ingesting yaml or dcf formatting but in the parsing of the key values themselves.

Worth noting that DCF is less structured than yaml and doesn't have a standard way of specifying lists/vectors, sometimes it's just comma-separated text, sometimes it's in R code.

[jennybc]

I think this looks pretty promising:

library(desc)

imports <- c(
  "Imports:",
  "    cli (>= 3.0.1),",
  "    clipr (>= 0.3.0),",
  "    crayon"
)

d <- desc(text = imports)
d$get_deps()
#>      type package  version
#> 1 Imports     cli >= 3.0.1
#> 2 Imports   clipr >= 0.3.0
#> 3 Imports  crayon        *

It seems desc is happy to operate on a DESCRIPTION fragment.

Update: or is this what you meant? I.e. that we still have ">= 3.0.1" as the version.

[lionel-]

That's what I thought at first but I still needed to extract the comparison and the version.

[lionel-]

I think the question of using DCF vs yaml is mosty orthogonal to this PR but here is a summary of my views:

• From the user point of view, the advantage of DCF is the familiar syntax for the fields that happen to be the same in meaning and syntax, e.g. Imports:. The advantage of yaml is to be consistent with other configuration headers such as Rmd or quarto.

• From the developer point of view, DCF has the disadvantage of not having list syntax. This means that nested lists can't easily be parsed unless they are supplied in another language for a second round of parsing, e.g. R code.

• For the cases where existing DCF/Description tooling can be leveraged, it's easy to assemble a DCF field since ambiguities only arise for extracting list elements, not assembling them. Ideally though, such tooling would have variants that accept character vectors of list elements so that they can be flexibly used with different formats.

[jennybc]

I added some documentation: basically taking info implicit in various parts of the PR and exposing it in the help.

It still seems like a lot of bespoke work to add this feature, but I guess it's just a fussy task.