From Kurt.Hornik at wu-wien.ac.at  Fri Apr 21 10:20:32 2006
From: Kurt.Hornik at wu-wien.ac.at (Kurt Hornik)
Date: Fri, 21 Apr 2006 10:20:32 +0200
Subject: [Rd] R CMD check: non source files in src on (2.3.0
	RC	(2006-04-19 r37860))
In-Reply-To: <787C4179-E8D8-449F-B83B-A04F9A669BD2@r-project.org>
References: <44472D38.80603@berkeley.edu>
	<Pine.LNX.4.64.0604200752001.14307@gannet.stats.ox.ac.uk>
	<59d7961d0604201023h18c8cf68t51b6ca3f2cbe578b@mail.gmail.com>
	<787C4179-E8D8-449F-B83B-A04F9A669BD2@r-project.org>
Message-ID: <17480.38352.565554.514650@mithrandir.hornik.net>

>>>>> Simon Urbanek writes:

> On Apr 20, 2006, at 1:23 PM, Henrik Bengtsson (max 7Mb) wrote:
>> Is it a general consensus on R-devel that *.tar.gz distributions  
>> should only be treated as a distribution for *building* packages  
>> and not for developing them?

[Actually, distributing so that they can be installed and used.]

> I don't know whether this is a general consensus, but it definitely  
> an important distinction. Some authors put their own Makefiles in src  
> although they are not needed and in fact harmful, preventing the  
> package to build on other systems - only because they are too lazy to  
> use R building mechanism for development and don't make the above  
> distinction.

Right :-)

Henrik, as I think I mentioned the last time you asked about this: of
course you can basically do everything you want.  But it comes at a
price.  For external sources, you need to write a Makefile of your own,
so as to make it clear that you provide a mechanism which is different
from the standard one.  And, as Simon said, the gain in flexibility
comes at a price.

Personally and as one of the CRAN maintainers, I'd be very unhappy if
package maintainers would start flooding their source .tar.gz packages
with full development environment material.  (I am also rather unhappy
about shipping large data sets which are only used for instructional
purposes [rather than providing the data set "on its own"].)  It is
simply not true that bandwidth does not matter.

If there is need, we could start having developer-package repositories.
However, I'd prefer a different approach.  We're currently in the
process of updating the CRAN server infrastructure, and should be able
to start deploying an R-forge project hosting service "eventually"
(hopefully, we can set things up during the summer).  This should
provide us with an ideal infrastructure for sharing developer resources,
in particular as we could add QC testing et al to the standard community
services.

Best
-k



[Rd] R CMD check: non source files in src on (2.3.0 RC (2006-04-19 r37860))
Kurt Hornik