lockedata / starters Goto Github PK
View Code? Open in Web Editor NEWR Package 📦 for initializing projects for various R activities :nut_and_bolt:
Home Page: https://itsalocke.com/starters/
License: GNU General Public License v3.0
R Package 📦 for initializing projects for various R activities :nut_and_bolt:
Home Page: https://itsalocke.com/starters/
License: GNU General Public License v3.0
At the moment I removed the Travis and coverage activation parts because they depended on the project already using GitHub.
use_github()
can't work on Windows yet because of git2r
. I'll either wait for it to work on all OS, or re-write some Travis/coverage stuff, just copy pasting templates at creation, and browsing the right pages afterwards.
@stephlocke if you re-install pRojects
now, you get less when creating a package, but this will be fixed soon, sorry about that.
Enable people to define a custom templates dir to search first, before relying on devtools defaults
Using praise
. praise::praise("First commit of this ${adjective} project, ${exclamation}!")
and have the explicit arguments instead?
As we use package skeletons, names folks can use are subject to R package naming rules. This causes bad user errors right now e.g. #36 and we should add some validation and documentation around the rules.
https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-DESCRIPTION-file
instead of devtools
to replace part of the code
Allow for author name, email etc to be set and then automatically populated in the DESCRIPTION when creating packages. These parameters can be included as function arguments as well, but should ideally be fetched by default so that they don't need to be specified repeatedly - I assume this is possible either by setting these parameters as options or via currying or something like that?
ProjectTemplate is fairly well established. Obviously it takes things much further in terms of enforcing templates, project structure etc, so I suppose one could view createAnalysisProject()
as a more lightweight alternative to it.
Nevertheless, given that it has a fair amount of traction, I figure it's worth considering how we want to approach this functional overlap. Any thoughts on this?
Cover the what and why of the methodology expected by createTrainingProject and suggest next steps for user
This might not be appropriate for the intended audience, but I figure if the primary goal is to prevent unnecessary typing and/or function calls in the process of setting up projects, packages etc, then maybe having these available from a drop-down might be useful. Could potentially even create a Shiny gadget using miniUI in order to facilitate input of the few required parameters for the high level functions.
Currently, we leave a directory lying around if the create*()
s fail - we should put a try catch or something in so that if things error along the way the dir is dropped.
For the skeleton docs (#2), have a script that produces them and sends to gh-pages branch or docs/
This could then be added to .travis.yml
I do not understand
# Installation dir
usePackrat <- !methods::hasArg("packrat")
if (!usePackrat)
usePackrat <- list(...)[["packrat"]]
installDir <- ifelse(usePackrat, name, .libPaths())
yet, I need to have a proper look.
I went kind of old school with createBasicProject()
- I feel like we could also offer create_basic_project()
for people with aesthetic objections to the old school naming convention without breaking things substantially for any existing users of the package.
This should be doable with extra code at the bottom of the function R files like
#' @describeIn createBasicProject
create_basic_project = createBasicProject
Since we want to have test failures in case of issues, not empty tests?
using temporary directories like in tests.
After checking there was a project set, of course.
Otherwise right now you end up with the project (for usethis
) to be set to the one you created, not the one you started from.
Current iterations of functions assume you want to create a directory below your current one. Modify the functions to allow a path to be provided.
I 👀 a logo in images. @stephlocke should I put it in the README? If so assign it to me 😉
For the skeleton docs (#1), have a script that produces them and sends to gh-pages branch or docs/
This could then be added to .travis.yml
Hi, thank you for your package. Today I got an error when I tried to create a new package with underscore or hyphen, as below:
pRojects::createTrainingProject(name = "sample-one",
dirs = c("data", "handouts", "slides"),
handoutEngine = "rmarkdown",
slideEngine = "rmarkdown",
travis = F, packrat = F, git = F, readme = TRUE)
#> Creating skeleton
#> Error: sample-one is not a valid package name: it should contain only
#> ASCII letters, numbers and dot, have at least two characters
#> and start with a letter and not end in a dot.
This code created an empty folder with the name sample-one
. Do you have any idea? Sometimes, it is inconvenient without the hyphen to name a project. Now my solution is a name without the hyphen first, then rename it later.
Or define availability differently then? E.g. not trying to create a repo with the same name as another repo.
In createPackageProject
https://github.com/lockedata/pRojects/blob/master/R/createPackageProject.R#L26
I'd be in favour of adding an argument readmeFormat
that could be "md" or "Rmd" ("Rmd" by default which shall motivate me to set up Travis build of the README 😁 ). Then either usethis::use_readme_rmd
or usethis::use_readme_md
would be used (with the git hook made by usethis
).
I'd moreover make the README creation happen no matter the value of bestPractices
because it seems easier than explaining that if bestPractice
is FALSE the readme_format
argument is ignored.
Auto-clean code before it get's committed perhaps?
http://styler.r-lib.org/
Probably as part of tic.R or so
under the user/org account. That could be used in all functions.
Add ability to include spellchecking via hunspell to projects
Cover the what and why of the selected use_* statements in createPackageProject and suggest next steps for user
Create some templates that can be added to createTrainingProject
Cover the what and why of the expected methodology in createAnalysisProject and suggest next steps for user
Have some default value for earliest R version to go in R DESCRIPTIONs
We currently use the full bookdown-demo repo, but I'm considering the nookdown-minimal one instead. It means a smaller install and less stuff someone might have to remove.
What do y'all think?
Create some templates that can be added to createAnalysisProject
Create a dummy GitHub account for that?
The dev version of devtools has a new README.Rmd template file called omni-README.
We should detect devtools version and pass in the relevant file name for that version to make it compatible with planned changes to devtools.
Currently "Manage Project Directories for R Projects" which doesn't reflect well the intended power of the package.
Important especially since the website uses that description as page title.
Should we add a pre-commit hook that will run good practice? It might make it so that if only if it passes it would commit - that's probably too onerous.
Perhaps just adding it to the pRojects Suggests?
I was running into some problems creating project dirs because of packrat. It doesn't like dropbox doing indexing at the same time as it's doing its thing. I don't think we need to do anything but I'm interested in people's thoughts
* Adding packrat to Imports
Next:
Refer to functions with packrat::fun()
Initializing packrat project in directory:
- "C:/Users/steph/Dropbox/Locke Data/Locke Data Training/Classification/LogisticRegressionBasics"
Adding these packages to packrat:
_
packrat 0.4.8-1
Fetching sources for packrat (0.4.8-1) ... OK (CRAN current)
Snapshot written to "C:/Users/steph/Dropbox/Locke Data/Locke Data Training/Classification/LogisticRegressionBasics/packrat/packrat.lock"
Installing packrat (0.4.8-1) ...
Warning: unable to move temporary installation ‘C:\Users\steph\Dropbox\Locke Data\Locke Data Training\Classification\LogisticRegressionBasics\packrat\lib\x86_64-w64-mingw32\3.3.3\file22247e730c1\packrat’ to ‘C:\Users\steph\Dropbox\Locke Data\Locke Data Training\Classification\LogisticRegressionBasics\packrat\lib\x86_64-w64-mingw32\3.3.3\packrat’
otherwise, the GitHub repo created gets a lame default description.
The line after that calls packrat::init
and it seems that it calls a function that calls augmentRprofile
https://github.com/rstudio/packrat/blob/eaf443593fc48ca2a3ebc724e3a3297b6a6a9b69/R/packrat.R
But I've close to no packrat
experience.
In https://cran.r-project.org/web/packages/checkpoint/vignettes/checkpoint.html I 👀 "Scans your project folder for all packages used. Specifically, it searches for all instances of library() and require() in your code."
At setup time, there's no packages used, only packages specified in DESCRIPTION, so checkpoint
does nothing, e.g. if I run it in createTrainingProject
I get
Scanning for packages used in this project
- Discovered 0 packages
No packages found to install
checkpoint process complete
and as far as I understood pRojects
philosophy, what we'd want is a package that'd get dependencies from DESCRIPTION (and help setup DESCRIPTION, but not bypass that step)? 🤔
The package currently calls to devtool::use_git()
when the Use git option is TRUE. The package also contains the option of including a data folder. git lfs (large file storage) is a useful extension to git that indexes file by type/location, and commits them to git in a safe way that doesn't lock up the repo when it's hosted externally, or slow it down if a large data set changes a lot.
Would it be technically possible to have a use git lfs button? I don't believe devtools has a wrapper to it, so any solution will probably have to be implemented slightly differently. If it were possible, would it be useful/desired?
As opposed to copying them from these package installations when using them?
@hrbrmstr started a project a while ago close to my heart hrbrmstr/swagger.
I'd like to revive that project to generate functions from API definitions produced in swagger - this would enable us to point at a swagger definition and produce not just a package skeleton with best practices but functions too.
We should facilitate pkgdown as it's nifty so that folks can build a package site more easily
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.