Hi
Quite a few R packages are now available on GitHub long before they
appear on CRAN, installation is simple thanks to
devtools::install_github(). However, it seems to be common practice to
keep the .Rd files (and NAMESPACE and the Collate section in the
DESCRIPTION) in the Git tree, and to
Hi,
this is maybe mostly a personal preference, but I prefer not to put
generated files in the vc repository. Changes in the generated files,
especially if there is many of them, pollute the diffs and make them
less useful.
If you really want to be able to install the package directly from
github
Gabor
I agree with you. There's Travis CI, and r-travis -- an attempt to
integrate R package testing with Travis. Pushing back to GitHub is
possible, but the setup is somewhat difficult. Also, this can be subject
to race conditions because each push triggers a test run and they can
happen in
Pushing back to github is not so difficult. See e.g
http://blog.r-enthusiasts.com/2013/12/04/automated-blogging.html
You can manage branches easily in travis. You could for example decide to do
something different if you are on the master branch ...
Romain
Le 13 déc. 2013 à 12:03, Kirill Mü
On 12/13/2013 12:50 PM, Romain Francois wrote:
> Pushing back to github is not so difficult. See e.g
> http://blog.r-enthusiasts.com/2013/12/04/automated-blogging.html
Thanks for the writeup, I'll try this. Perhaps it's better to push the
results of `R CMD build`, though.
> You can manage branche
On 12/11/2013 4:39 PM, Kirill Müller wrote:
Hi
Quite a few R packages are now available on GitHub long before they
appear on CRAN, installation is simple thanks to
devtools::install_github(). However, it seems to be common practice to
keep the .Rd files (and NAMESPACE and the Collate section in
On Fri, Dec 13, 2013 at 6:03 AM, Kirill Müller
wrote:
> Gabor
>
> I agree with you. There's Travis CI, and r-travis -- an attempt to integrate
> R package testing with Travis. Pushing back to GitHub is possible, but the
> setup is somewhat difficult. Also, this can be subject to race conditions
>
It seems like an easy solution to the "users don't know make" problem is to
provide a make file which runs any R code it finds in
pkg/inst/preinstall/preinstall.R, perhaps in dev_tools/inst/extras or
simply from a website.
That way the users don't need to know make, they just need to know what to
FWIW this is essentially what RForge.net provides. Each GitHub commit triggers
a build (branches are supported as the branch info is passed in the WebHook)
which can be either "classic" R CMD build or a custom shell script (hence you
can do anything you want). The result is a tar ball (which inc
Oh, I didn't know RForge.net supported external git repos, cool!
Gabor
On Fri, Dec 13, 2013 at 3:14 PM, Simon Urbanek
wrote:
> FWIW this is essentially what RForge.net provides. Each GitHub commit
> triggers a build (branches are supported as the branch info is passed in the
> WebHook) which c
Btw. one thing that probably would not work (well) with RForge.net (or
another CRAN-like repo), is the multiple branches.
The problem is that you cannot put the branch name in the package
version string, because that is not allowed, and then the versions
from the multiple branches get mixed up. Th
Thanks a lot. This would indeed solve the problem. I'll try mkdist today ;-)
Is the NEWS file parsed before of after mkdist has been executed?
Would you be willing to share the code for the infrastructure, perhaps
on GitHub?
-Kirill
On 12/13/2013 09:14 PM, Simon Urbanek wrote:
FWIW this i
On 12/13/2013 06:09 PM, Brian Diggs wrote:
One downside I can see with this third approach is that by making the
package documentation generation part of the build process, you must
then make the package depend/require roxygen (or whatever tools you
are using to generate documentation). This de
13 matches
Mail list logo
