Skip to content

Is there a way to source from a specific Git repository without hardcoding the location everywhere?

12 messages · Duncan Murdoch, Hadley Wickham, Daniel Nordlund +2 more

Duncan Murdoch
#
On 12-09-26 8:25 PM, Curt Seeliger wrote:
Yes.  Use

library(myProject)

where myProject is a package containing all the scripts, written as 
functions.

Duncan Murdoch
Hadley Wickham
# 
You might want to look at load_code in devtools (which is designing
for code stored in packages, but may work for your situation),
otherwise use only relative paths inside your project, and then ensure
people source(, chdir = T) one function that loads everything else.

If your example, all you need to do is
source("path/to/projectStart.r", chdir = T).

Hadley
Hadley Wickham
# 
Also, something that Duncan was probably thinking but didn't mention,
is that creating a package is really really easy - all you need to do
is put your R files in a directory called R and create a description
file that says what the package does, who's allowed to use it (the
license), who to contact if there are problems (author/maintainer) and
what other packages it requires (depends/imports).

Hadley
Duncan Murdoch
#
On 12-09-27 3:31 AM, Hadley Wickham wrote:
I would usually do more than that:  I find the R documentation system 
helpful even when I'm the only user of a package (and there are the 
prompt* functions for quickly creating it, as well as package.skeleton 
to set things up at the beginning).  Vignettes are a great way to 
organize and document things that are done via scripts.  And if you want 
to include compiled C or C++ or Fortran code, packages are drastically 
easier to manage than other approaches.

Duncan Murdoch
Hadley Wickham
# 
Me too - but I'd never write Rd by hand ;) instead relying on roxygen2
to automate as much of the process as possible. I also find that
having the code and documentation co-located makes it easier to keep
in sync.

But my point main was that it's very easy to start a package - and you
don't need every component of a package for it to be useful.  In fact
the point of packages is to make your life easier - it's a set of
conventions to follow so that you don't have to invent everything from
scratch. Once you have conventions, then it's easy to use tools that
others have written for performing common operations.  And in R, you
have several philosophies of tools to choose from.

Hadley
Daniel Nordlund
# 
Curt,

each user could set a PROJECT_PATH environment variable on the local machine, and then project script files could contain the code

setwd(Sys.getenv(c('PROJECT_PATH')))


Hope this is helpful,

Dan

Daniel Nordlund
Bothell, WA USA
Bert Gunter
# 
Curt:

Well, if you want to peer a bit more, you might wish to have a look at
http://inlinedocs.r-forge.r-project.org/ . Same philosophy as
Roxygen_x (keep docs together with code, generate Rd files
automatically therefrom) but takes a different approach.

Perhaps worth noting for both cases is that thermodynamics applies(you
can't get something from nothing): The simplicity you gain from
"standardization" when combining docs with code entails a certain loss
of flexibility in the organization and content of the .Rd files (which
you can, of course, always then manually edit by hand) You can decide
which, if either, of the packages strikes the right balance for you.

Cheers,
Bert

On Thu, Sep 27, 2012 at 8:45 AM, Curt Seeliger
<Seeliger.Curt at epamail.epa.gov> wrote: