Skip to content

Dealing with .git folder when using R CMD INSTALL

7 messages · Ralf Stubner, Dirk Eddelbuettel, Joris Meys

#
Dear all,

quite a few package tools depend on R CMD INSTALL today for rapid testing
of a package, eg:

- devtools::install()
- BiocCheck::BiocCheck()

I've noticed that at least BiocCheck() doesn't ignore version control
folders like .git. Trying to find out why this was, lead me to R CMD
INSTALL.

I know this R CMD build ignores these files and folders by default, but R
CMD INSTALL doesn't apparently. Is there a way to tell R CMD INSTALL to
ignore at least the .git folder, or are there plans to add this the R CMD
INSTALL? And if so, where do I file the request best?

Cheers
Joris
#
On 6 December 2018 at 15:19, Joris Meys wrote:
| Dear all,
| 
| quite a few package tools depend on R CMD INSTALL today for rapid testing
| of a package, eg:
| 
| - devtools::install()
| - BiocCheck::BiocCheck()
| 
| I've noticed that at least BiocCheck() doesn't ignore version control
| folders like .git. Trying to find out why this was, lead me to R CMD
| INSTALL.
| 
| I know this R CMD build ignores these files and folders by default, but R
| CMD INSTALL doesn't apparently. Is there a way to tell R CMD INSTALL to
| ignore at least the .git folder, or are there plans to add this the R CMD
| INSTALL? And if so, where do I file the request best?

Are you sure?  Eg from src/library/tools/R/utils.R:

## Version control directory names: CVS, .svn (Subversion), .arch-ids
## (arch), .bzr, .git, .hg (mercurial) and _darcs (Darcs)
## And it seems .metadata (eclipse) is in the same category.

.vc_dir_names <-
    c("CVS", ".svn", ".arch-ids", ".bzr", ".git", ".hg", "_darcs", ".metadata")

## and RE version (beware of the need for escapes if amending)

.vc_dir_names_re <-
    "/(CVS|\\.svn|\\.arch-ids|\\.bzr|\\.git|\\.hg|_darcs|\\.metadata)(/|$)"


(and many more similar places in the sources)

These have been auto-ignored by R CMD build for a loooooong time. Are you
maybe making the mistake of installing from a _directory_ as opposed to first
creating a tarball?

Dirk
#
On Thu, 6 Dec 2018, 15:37 Dirk Eddelbuettel <edd at debian.org wrote:

            
That's indeed what devtools::install () and BiocCheck () are doing, and I
wondered if R CMD INSTALL could be made to ignore at least those.

Thx for the confirmation
Cheers
Joris
#
On 06.12.18 15:19, Joris Meys wrote:
to me this is not apparent. I just tried "R CMD INSTALL ." in a package
directory with a .git directory. This went without any problems. What do
you observe?

cheerio
ralf
#
On Thu, 6 Dec 2018, 16:04 Ralf Stubner <ralf.stubner at daqana.com wrote:

            
When running BiocCheck, I get complaints about file sizes in the .git
folder. Checking the code I have noticed it uses R CMD INSTALL on the pkg
directory. As .Rbuildignore is afaik not taken into account by INSTALL, I
reckoned somewhere in the process R CMD INSTALL drags the .git folder along.

I might have been too quick with my assessment, I will dig a bit deeper
tonight

Cheers
Joris

  
  
#
On 6 December 2018 at 15:59, Ralf Stubner wrote:
| On 06.12.18 15:19, Joris Meys wrote:
| > I know this R CMD build ignores these files and folders by default, but R
| > CMD INSTALL doesn't apparently.
| 
| to me this is not apparent. I just tried "R CMD INSTALL ." in a package
| directory with a .git directory. This went without any problems. What do
| you observe?

Seconded. I joked off-list to Joris that this post failed to contain a MCVE
(== minimally complete verifiable example).  Witness below -- two
installations from a directory containing .git yet none in the installed
directory.  Could what you describe be particular to your OS or filesystem?

edd at rob:~/git/dang$ ls -a
.          dang_0.0.7.tar.gz  dang.Rproj   .gitignore  R              .Rhistory
..         dang_0.0.8.tar.gz  DESCRIPTION  man         .Rbuildignore  .Rproj.user
ChangeLog  dang.Rcheck        .git         NAMESPACE   README.md      .travis.yml
edd at rob:~/git/dang$ R CMD INSTALL .
* installing to library ?/usr/local/lib/R/site-library?
* installing *source* package ?dang? ...
** R
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (dang)
edd at rob:~/git/dang$ ls -a /usr/local/lib/R/site-library/dang/
.  ..  DESCRIPTION  help  html  INDEX  Meta  NAMESPACE  R
edd at rob:~/git/dang$ install.r 
* installing *source* package found in current working directory ...
* installing *source* package ?dang? ...
** R
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
* DONE (dang)
edd at rob:~/git/dang$ ls -a /usr/local/lib/R/site-library/dang/
.  ..  DESCRIPTION  help  html  INDEX  Meta  NAMESPACE  R
edd at rob:~/git/dang$


Dirk
#
I'm sorry, I should have indeed given a better description.

The package I'm seeing the issue with, can be found here :
https://github.com/CenterForStatistics-UGent/RCM

The problem becomes visible when opening an RStudio session and running
BiocCheck::BiocCheck() (This is a Bioconductor package)
This is BiocCheck version 1.18.0. BiocCheck is a
work in progress. Output and severity of issues may
change. Installing package...
* Checking vignette directory...
    This is a software package
    # of chunks: 39, # of eval=FALSE: 4 (10%)
* Checking version number...
    Checking version number validity...
    Package version 0.99.0; pre-release
* Checking R Version dependency...
* Checking package size...
        Skipped... only checked on source tarball
* Checking individual file sizes...
    * WARNING: The following files are over 5MB in size:
      '.git/objects/pack/pack-92e66ff77b78e7fa5121747871adeaa41fb1feb6.pack'
...

And at this point I start hitting myself so I can utter an apology and
inform you that BiocCheck doesn't check filesize on the installed package
but on the original project directory.

My mistake, and I should have been more careful before bothering you all.
Cheers
Joris
On Thu, Dec 6, 2018 at 4:14 PM Dirk Eddelbuettel <edd at debian.org> wrote: