For various reasons, I've opted to make my packages available from my
own web page rather than submitting them to CRAN (mostly laziness -- for
a long time I didn't have the packages quite cleaned up enough to pass all
the tests). It occurred to me to wonder about the scripts used by CRAN
maintainers to generate the PACKAGES file, and to generate PACKAGES.html
from PACKAGES. Are those something that could be made available? Or
do people think that I should bite the bullet and submit my packages to
CRAN instead?
Ben Bolker
318 Carr Hall bolker@zoo.ufl.edu
Zoology Department, University of Florida http://www.zoo.ufl.edu/bolker
Box 118525 (ph) 352-392-5697
Gainesville, FL 32611-8525 (fax) 352-392-3704
maintainers to generate the PACKAGES file, and to generate PACKAGES.html
from PACKAGES. Are those something that could be made available? Or
do people think that I should bite the bullet and submit my packages to
CRAN instead?
You might want to take a peak at the 'reposTools' package distributed by
the Bioconductor project (www.bioconductor.org). Specifically, take a
look at the three vignettes about reposTools at:
http://www.bioconductor.org/viglistingindex.html
One of the vignettes details how to construct a small repository of
packages.
There are HTML generation tools provided by the package if you wish to
distribute your packages via the web. Also, why the standard
install.packages()/etc don't work with a reposTools repository it does
include its own set of client side functions XXX.packages2(), which are
detailed in the vignette on accessing repositories.
The package itself can be downloaded from the site, either in it's
released version:
http://www.bioconductor.org/repository/release1.1/package/html/index.html
or developmental version:
http://www.bioconductor.org/repository/devel/package/html/index.html
HTH
-Jeff
Though you might also want to look at Bioconductor's reposTools package,
which is designed to manage packages with multiple repositories.
Is there any chance of a CVS repository for public but not necessarily
CRAN-quality R Code? Or better still, a sourceforge-type site (ForgeRy?)
based on GForge with all the goodies that such sites have for
cooperative development (forums, task management, bug tracking etc). I
already have a couple of projects on sourceforge but I think its a bit
daunting for new people. Perhaps an R-specific forge site would be more
welcoming?
Or even better better still, an entire web-based R community site,
with discussions and news and code snippets and words of wisdom
something like www.perlmonks.org?
I'll be at DSC2003 if anyone wants to beat me senseless with a tree
for suggesting this.
Baz
OK, then, one more concern: I'm trying to decide on an appropriate level
of resolution for distributing packages. At the moment I have "bbmisc",
which is a package bundle consisting of about 6 packages of varying size
and specificity -- does that seem reasonable? Or do people prefer more,
smaller bits on CRAN?
Ben
On Tue, 4 Mar 2003, Dirk Eddelbuettel wrote:
On Tue, Mar 04, 2003 at 11:39:51AM -0500, Ben Bolker wrote:
do people think that I should bite the bullet and submit my packages to
CRAN instead?
Yes please.
Dirk
318 Carr Hall bolker@zoo.ufl.edu
Zoology Department, University of Florida http://www.zoo.ufl.edu/bolker
Box 118525 (ph) 352-392-5697
Gainesville, FL 32611-8525 (fax) 352-392-3704
"Ben" == Ben Bolker <ben@zoo.ufl.edu>
on Tue, 4 Mar 2003 13:19:16 -0500 (EST) writes:
Ben> OK, then,
you are aiming at CRAN, thank you.
In spite of the reposTools developments mentioned, I agree with
Dirk that it's best submitting to CRAN -- at least for the time being.
One strong argument for CRAN is that the R Core team "looks"
(via grep etc) at the CRAN sources frequently in deciding about
new features, possible back-compatibility breaking changes etc etc.
Also the CRAN maintainers daily check all CRAN packages against
the curren *development* version(s) of R -- and make sure
CRAN packages continue to run "R CMD check" -- or the package
maintainer is notified about something we consider an ``infelicity'',
(e.g. using non-API C calls into R code; using "internal" R
functions that might be changed, etc etc).
Ben> one more concern: I'm trying to decide on an
Ben> appropriate level of resolution for distributing
Ben> packages. At the moment I have "bbmisc", which is a
Ben> package bundle consisting of about 6 packages of
Ben> varying size and specificity -- does that seem
Ben> reasonable? Or do people prefer more, smaller bits on
Ben> CRAN?
Many from R core would prefer stand-alone packages instead of
bundles quite a bit. {some have even proposed to drop bundle support.}
If you have one ``base package'' and all the other just needing
that one, I'd put something like stopifnot(require(mybasepkg)) statements
in the .First.Lib of the other packages and still put them on
CRAN separately.
If you have very good reasons for the bundle, well..
Ben> On Tue, 4 Mar 2003, Dirk Eddelbuettel wrote:
>> On Tue, Mar 04, 2003 at 11:39:51AM -0500, Ben Bolker wrote:
>> > do people think that I should bite the bullet and submit my packages to
>> > CRAN instead?
>>
>> Yes please.
>>
>> Dirk
>>
Regards,
Martin Maechler <maechler@stat.math.ethz.ch> http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27
ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND
phone: x-41-1-632-3408 fax: ...-1228 <><
Many from R core would prefer stand-alone packages instead of
bundles quite a bit. {some have even proposed to drop bundle support.}
...
Don't keep bundle support around just on my account. The one thing that I think
is useful is that the inter-dependencies in my packages also depend on package
versions, and I don't think require() checks versions. By putting the packages
in a bundle I am relatively sure a user will get versions of the packages that
are suppose to work together. Of course, this is a bigger problem than just my
packages, so a more comprehensive solution would be better.
Paul Gilbert
versions, and I don't think require() checks versions. By putting the packages
in a bundle I am relatively sure a user will get versions of the packages that
are suppose to work together. Of course, this is a bigger problem than just my
packages, so a more comprehensive solution would be better.
This is also a problem that reposTools attempts to solve. Currently when
you try to install/update/download a package from a repository, it will
compare dependencies (listed in the "Depends" field of DESCRIPTION) and
retriee the specified packages/versions.