pkgdown 1.6.1 `build_site()` warning due to incomplete final line

Created on 6 Oct 2020  路  10Comments  路  Source: r-lib/pkgdown

I'm seeing a warning like this pop up consistently for my pipette package:

Warning message:
In readLines(file) :
  incomplete final line found on '/var/folders/l1/8y8sjzmn15v49jgrqglghcfr0000gn/T//RtmpK4yEYw/file10c2611bb97d1'

I've attached the file10c2611bb97d1 file causing the warning with readLines.
file10c2611bb97d1.txt

As you can see, this file contains documentation for jsonlite, which is imported by pipette. I can confirm that this file doesn't contain an expected EOL line break, which causes readLines to warn. Note that readr::read_lines() handles this situation without a warning, as a possible solution.

Most helpful comment

I have it. The file missing the closing LF is an article about jsonlite in the URL field of its DESCRIPTION, https://arxiv.org/abs/1403.2805 . The message can be triggered by running downlit::autolink_url("jsonlite::fromJSON") in a clean R session. (The 2nd run won't trigger it, because of caching.)

Tracing down through the downlit::autolink_url call, it eventually downloads that URL in downlit:::fetch_yaml and tries to read it using yaml::read_yaml. That function uses string <- paste(readLines(file), collapse = "\n") to read the file, which gives the warning.

So probably the solution is for downlit to suppress warnings when calling yaml::read_yaml. I'll submit a PR.

All 10 comments

I don't think this can be a pkgdown problem because we have:

readLines <- function(...) stop("Use read_lines!")

read_lines <- function(path, n = -1L) {
  base::readLines(path, n = n, encoding = "UTF-8", warn = FALSE)
}

FWIW I see this too, consistently, when I build pkgdown sites locally:

Warning message:
In readLines(file) :
  incomplete final line found on '/tmp/RtmpIIbBlg/file1c11148e44ed'

Could it be coming from a more indirect call to readLines()?

@jennybc That was my thought too but I couldn't figure out a way to track that down in a stack trace. I think I only have 1 package currently that generates this warning. I'll take a look again and see if I come across any useful info.

I have completely failed to debug this but let me at least record what I've observed and tried:

I only see the warning with pkgdown:::build_site_external(). (I'm currently seeing it with gargle, in case that possibly matters).

Having options(warn = 2, error = utils::recover) in effect for the current R session has no effect (no surprise, but this did lead to discovering a completely unrelated partial match warning (20c4390517f26189bf7743ae530cb0ec3f8e8800).

Putting warn = 2 in these options in the external process makes the problem go away 馃お

https://github.com/r-lib/pkgdown/blob/20c4390517f26189bf7743ae530cb0ec3f8e8800/R/build.r#L390-L394

I also just replicated the warning with httr, so it's not specific to gargle. But I don't see it with pkgdown itself or with reprex.

In the case of httr, I think the error happens when processing write_disk.Rd. I set a breakpoint in R at the point the warning was being issued. The breakpoint was triggered just after the status line

Reading 'man/write_disk.Rd'

was printed. The example in that help page generates an "incomplete last line" warning, but with a different filename, which seems like quite a coincidence.

EDITED TO ADD: Sorry, I was just seeing the example generate the warning. So all I can contribute is that nothing else in that process generated the one that's showing up in the console.

I have it. The file missing the closing LF is an article about jsonlite in the URL field of its DESCRIPTION, https://arxiv.org/abs/1403.2805 . The message can be triggered by running downlit::autolink_url("jsonlite::fromJSON") in a clean R session. (The 2nd run won't trigger it, because of caching.)

Tracing down through the downlit::autolink_url call, it eventually downloads that URL in downlit:::fetch_yaml and tries to read it using yaml::read_yaml. That function uses string <- paste(readLines(file), collapse = "\n") to read the file, which gives the warning.

So probably the solution is for downlit to suppress warnings when calling yaml::read_yaml. I'll submit a PR.

@dmurdoch thanks for all the investigation! Would you mind also doing a PR to yaml itself so that we can fix this problem for others too?

I did submit the yaml PR, but it's not so clear to me that it's appropriate. Maybe the YAML spec requires the terminal LF? The case here was caused by reading a non-YAML file, looking for YAML.

The 2nd run won't trigger it, because of caching

Aha! I expect some of my observations were spurious and due to coincidences re: the order in which I tried things.

Was this page helpful?
0 / 5 - 0 ratings