unable to install seqinr about rocker

[cboettig]

I can't replicate this; it works fine for me. Are you sure you have the
most recent rocker/r-base? (I'm on image 84bd0646c215)

On Fri, Oct 24, 2014 at 10:45 AM, Karl Forner [email protected]
wrote:

docker run -t rocker/r-base Rscript -e 'install.packages("seqinr")'
...
** R
Warning in parse(outFile) :
invalid input found on input connection '/usr/local/lib/R/site-library/seqinr/R/seqinr'
Error in parse(outFile) :
/tmp/RtmpCwXuIp/R.INSTALL1a409031a/seqinr/R/synonymous.R:69:0: unexpected end of input
67: })
68: usage = uco(sequence)[allcodons] #r
^
ERROR: unable to collate and parse R files for package ‘seqinr’

• removing ‘/usr/local/lib/R/site-library/seqinr’

The downloaded source packages are in
‘/tmp/RtmpitkBKh/downloaded_packages’
Warning message:
In install.packages("seqinr") :
installation of package ‘seqinr’ had non-zero exit status

This seems to be an encoding issue, there's a french accent at
seqinr/R/synonymous.R:69:0.
But I wonder: could we not just set the same setting than the CRAN check
process ?

Thanks.

—
Reply to this email directly or view it on GitHub
#58.

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

[wch]

Works for me also. Maybe you need to do a docker pull rocker/r-base?

[eddelbuettel]

Same here. Makes you 0 for 3. I'm closing this.

[kforner]

Sorry, I did Not pull. Thought docker run did.

[HenrikBengtsson]

FYI, today I received a very similar issue HenrikBengtsson/R.utils#3 related to installing R.utils on CRAN from source. Interestingly, this is also from a user using docker ("ubuntu:14.04 inside boot2docker VM"). Myself, I fail to reproduce the installation errors on Linux and Windows under various locale settings.

My working hypothesis is that this has to do with non-ASCII ("7 bit") characters in source-code comment. Note that non-ASCII is allowed in source-code comments, but not in code (http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Package-subdirectories);

Only ASCII characters (and the control characters tab, formfeed, LF and CR) should be used in code files. Other characters are accepted in comments, but then the comments may not be readable in e.g. a UTF-8 locale. Non-ASCII characters in object names will normally10 fail when the package is installed. Any byte will be allowed in a quoted character string but \uxxxx escapes should be used for non-ASCII characters. However, non-ASCII character strings may not be usable in some locales and may display incorrectly in others.

What "readable" means is not clear, but I assume it means "human readable". This is why I conclude non-ASCII characters are allowed in comments.

In the R.utils case, I found one source file containing é (0xE9) in comments. Removing this "offending" comment, the package installs correctly, cf. HenrikBengtsson/R.utils#3.

Finding this thread, I checked seqinr 3.1.2. Sure enough, in R/synonymous.R, there is a comment containing non-ASCII characters:

    usage = uco(sequence)[allcodons] #ré-ordonner selon NCBI

In this case, it's also a é (0xE9) character. In case you wonder, these two source codes are not using UTF-8 or UTF-16 and there is no BOM sequence or similar. They are plain 8-bit ASCII files.

Keep searching, I found rocker issue #40, which reports on a similar issue with the bit package, and that package also contains comments with non-ASCII character, e.g.

"# (c) 2010 Jens Oehlschl\xe4gel"

Now look at this:

# Create a small foo.R file with a non-ASCII comment
> bfr <- as.raw(c(0x23, 0x20, 0x61, 0xe9, 0x65, 0x62, 0x0a))
> writeBin(bfr, con="foo.R")
> readLines("foo.R")
[1] "# a\xe9eb"

> Sys.setlocale("LC_CTYPE", "C")
[1] "C"
> parse("foo.R")
expression()

> Sys.setlocale("LC_CTYPE", "en_US.UTF-8")
[1] "en_US.UTF-8"
> parse("foo.R")
expression()
Warning message:
In grepl("\n", lines, fixed = TRUE) :
  input string 1 is invalid in this locale

I don't know if using the "C" locale is a solution or just a coincidence, because even with "en_US.UTF-8" I cannot reproduce the original installation issues. Related, in tools:::.install_package_code_files(), there is an effort of using the "C" locale for collating the source files.

I see that @eddelbuettel maybe onto something in Issue #40:

I'd look at what the base R tools package does. By allowing for old-world encodings, you may need to set some explicit overrides.

To conclude, a workaround for package developers seems to use only (7-bit) ASCII characters throughout all source code files - also in comments.

I leave it at this for now; maybe someone else will find this comment and further narrow the installation problem(s).

- And another day passed troubleshooting.

[eddelbuettel]

Nice work.

It sort of rings bell from when we did cran2deb (ie automated .deb creation of all CRAN packages; we stopped a few years but the idea lives on in eg http://debian-r.debian.net by Don) and I think I had to once or twice override exotic chars. I am pretty sure one package by Jens was among them.

I generally think it is not worth putzing with this. I think I have also seen R itself use "C" as a local prior to some other system() calls.

Quick check confirms:

edd@max:~/svn/r-devel/src/library/tools$ grep "\"C\"" R/* | wc -l
28
edd@max:~/svn/r-devel/src/library/tools$ 

Not worth arguing with, is it?

[HenrikBengtsson]

It's getting late and brain is shutting down so I'm not sure what you mean with you're last comment; are you saying there is an inherent problem with how encoding in handled in R and all those (28) cases indicates there are lots of ad hoc workarounds in R? Or maybe you mean something else.

In tools:::.install.packages(), I found the following comment interesting:

        ## This cannot be done in a C locale
        res <- try(.install_package_code_files(".", instdir))
        if (inherits(res, "try-error"))
        pkgerrmsg("unable to collate and parse R files", pkg_name)

Someone already thought about this and decided against using the C locale! It would be nice if one could conclude if this is something that should/could be fixed in R or not.

[HenrikBengtsson]

So, after finding e260a42, I can reproduce the installation issues reported here (#40 and #58) and elsewhere (HenrikBengtsson/R.utils#3) myself. Is it your understanding that it is all due to setting the encoding at startup (which is always used by install.packages() unless you do some tricks)?

[eddelbuettel]

I don't know. I usually found ways to avoid the issue.

If you think it is an R issue, you should take it up on r-devel. To me, the "R installation is the spec" so if a package breaks, I change the package.

[HenrikBengtsson]

I ended up posting 'SUGGESTION: Force install.packages() to use ASCII encoding when parse():ing code?' to R-devel.

[eddelbuettel]

Saw it, good move. Like the follow-up as well ("hell yeah, in principle other charsets ought to work") but maybe that needs more work.