search

nickmckay / LiPD-utilities

Input/output and manipulation utilities for LiPD files in Matlab, R and Python
http://nickmckay.github.io/LiPD-utilities/
GNU General Public License v2.0
29 stars 9 forks source link

Clean up R pkg folder #17

Closed gavinsimpson closed 7 years ago

gavinsimpson commented 7 years ago

Several hidden files had polluted the R pkg directory. This PR deletes those files and modifies the repo .gitignore and the R pkg-specific .Rbuildignore files to make sure these and other extraneous files do not get committed in the future.

In particular I use recursive syntax in .gitignore so it finds the intended files no matter where they occur in the repo filesystem.

I also added lipd.Rproj to the list of files to ignore when building the R pkg tarball.

gavinsimpson commented 7 years ago

I just noticed @chrismheiser has just dealt with some of this whilst I was preparing my changes. I'd suggest that instead of the changes to .gitignore which will only work in the R folder (there was a .Rhistory in the R/R repo folder, which wouldn't get caught by the new rules) that the one's I specified in this PR be used as they'll catch user/hidden files no matter where.

Also, the .Rbuildignore was deleted in a recent change, but you need that (probably without the default RStudio project file flags) to exclude the lipd.Rproj file from the package build process otherwise R CMD check will complain.

nickmckay commented 7 years ago

Thanks @gavinsimpson . Thanks for the PR and the fixes. We're in the middle, mostly @chrismheiser of making some updates and improvements to the utilities and the packages. I assume you're checking out the repo to play around with some LiPD data from the PAGES 2k compilation. We're eager to learn how well the package is working, especially as we're making updates, and let us know if you have any questions.

gavinsimpson commented 7 years ago

@nickmckay You guessed right (about the paper) but I also noticed quite a few things when I was building the pkg locally that I'm tuned to spot from working with rOpenSci. Is it worth me fixing things or should I just file issues and then you or @chrismheiser can tell me if they've been fixed locally or not before I fix them?

chrismheiser commented 7 years ago

@gavinsimpson I was trying to mess with the gitignore for the hidden R files. It didn't seem like the recursive rules I had were picking up the hidden files (since they have continued to update with commits). That's why I was trying out the explicit paths. Thanks for the fixes!

nickmckay commented 7 years ago

Thanks @gavinsimpson , your ROpenSci experience is welcome as we're pretty new to the R package game. Normally I think our preference would be for you to go ahead and make the corrections and pull requests, but since @chrismheiser is actively working on things it might be easier to report issues. @chrismheiser , do you have a preference?

gavinsimpson commented 7 years ago

@chrismheiser The recursive syntax ** was news to me, but I checked it locally and it worked. I think it is best to try to match them globally from the repo root as anyone could easily start R in any of the other folders.

chrismheiser commented 7 years ago

@nickmckay No preference. @gavinsimpson Feel free to fix as you please. Ah, for some reason I thought that * was recursive, but now I realize that doesn't make much sense regarding the other ways * is used. Thanks for the tip.

gavinsimpson commented 7 years ago

Thanks both; if it's something that's probably easier for @chrismheiser to fix (like the bam.py issue I just filed, I do as I did there and file and Issue. If it's something R-specific I'll fix or edit and then do a PR.

Probably best to close this PR without trying to fix the conflicts and just make the .gitignore and .Rbuildignore changes yourself.