[R] How to pack my stuff into a package (library, collection)?
Duncan Murdoch
murdoch at stats.uwo.ca
Tue Apr 8 01:16:42 CEST 2008
On 07/04/2008 11:51 AM, Tribo Laboy wrote:
> On Mon, Apr 7, 2008 at 11:09 PM, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
>> On 4/7/2008 9:33 AM, Tribo Laboy wrote:
>> ...
>>
>>
>>> Hi Duncan,
>>>
>>>
>>> Thanks for your reply. I checked the Rtools and the other relevant
>>> tools. I will most probably install them, although unwillingly.
>>> Unwillingly, because I like my current setup very much, which is a
>>> portable installation of R. I run it on the 5 different machines that
>>> I use and it is very easy to sync no mater where I install new or
>>> updated packages. I will probably have to designate one of the
>>> machines as a development machine and the others will be run-only, but
>>> this is very similar to compiled languages. Is there any way to set
>>> them up inside the main R directory structure, independent of the
>>> operating system, variables, etc.?
>>>
>> I don't think it will ever be possible to share installed packages across
>> different platforms. The issue is that the different operating systems have
>> different requirements for an installed package. For example, Unix-alikes
>> have soft links and make use of them; Windows installs don't. (Recent
>> Windows versions have something similar, but they are so rarely used that I
>> think it would be a bad idea to use them.) There are also differences in
>> what functions are available in R in the different platforms (e.g. there's
>> no windows() graphics device except on Windows), and some packages may
>> install different things depending on the target platform.
>>
>> So to do what you want to do, I'd suggest setting up a mini-repository for
>> source packages, and updating from there whenever necessary.
>>
>>
>>
>>> Once again, it would be very helpful to clarify what is it that is
>>> needed to run my R-files and what INSTALL does (I did ?INSTALL, but I
>>> am none the wiser).
>>>
>> I think the best thing to do is to look at the source code. The
>> documentation will necessarily be a little general and abstract; if you want
>> to know exactly what it does, just look.
>>
>>
>> As a user I can do without all the bells and
>>
>>> whistles of a HTML or chm-help and just some command line parsing of
>>> the Rd help files is just fine.
>>>
>> I'm not sure what you mean by "command line parsing" of the help files, but
>> you can certainly set things up to avoid CHM help, and that makes package
>> installation easier on Windows. I am inclined to make HTML help the default
>> in 2.8.0, so that by default you won't need the CHM compiler: but that
>> won't be until the fall, and there may be objections to the change.
I took a look at this today. You get an error message but the package
is still installed without the CHM compiler, so that's less urgent.
I did add a menu entry to install a source package from a directory:
Packages | Install source package from local folder...
to the alpha version. I don't guarantee this will survive testing: it
gives a fairly ugly error message if you don't have Rtools installed.
Duncan Murdoch
>>
>>
>>
>>> Obviously, I can run my functions when
>>> "sourced" and I do not interface to FORTRAN or C, so I do not
>>> understand what more is needed.
>>>
>> I agree that we should make it easier to install packages without compiled
>> code, and I think if you look at the evolution of Rtools over the years,
>> you'll see that we have. We aren't done yet.
>>
>>
>>
>>> Is it a namespace issue or just help
>>> file compilation? Whatever it is, I suspect that this rigid INSTALL
>>> and package build process is very helpful to enforce good quality
>>> packages on CRAN with good quality documentation. But isn't it an
>>> overkill for average Joe Programmer, who will never submit
>>> 'joes_weighted_mean' package to CRAN?
>>>
>> I don't think so. I think even Joe benefits from the QA support in R. But
>> if he doesn't want to make use of it, he does have the option of just
>> source'ing the code.
>>
>>
>>
>>> Anyway, if you'd have some piece of advice, I'd really appreciate it.
>>>
>> Two pieces:
>>
>> 1. Do install Rtools, but read the options carefully. You can get a
>> smaller install by leaving out some optional components. It's still likely
>> to be on the order of 50 MB installed, because we rely on Perl, and it's
>> about 40 MB. Now, 50 MB sounds like a lot (it's more than twice the size of
>> the hard drive on my first PC), but it's just 2.5% of the size of the USB
>> thumb drive in my pocket, and less than 0.02% of the size of the hard drive
>> in the PC I just bought for my mother. It's really trivial for most people.
>>
>> 2. Study the install process, and identify ways in which we could make it
>> easier for people in your circumstances without making it harder for
>> everyone. Let us know, and contribute documentation or patches that do it.
>>
>> Duncan Murdoch
>>
>
>
> Hi again,
>
> Thanks for the advice. I do not mind the 40 MB or 50 MB. Still I'd
> hope it would be possible to avoid it if full blown cross-platform
> packages for CRAN are not needed. I am not a Perl hacker, but from
> what I saw in the INSTALL source most of the calls that do the stuff
> are to the system and zip utils, the other parts are Windows help-file
> building (on Windows), housekeeping and checks, as far as I can tell.
> For people in my situation (personal pure R packages), probably all
> the checks if an older version exists or not are not so important, as
> aren't the windows help-files. A command line parsing of the Rd files
> will go a long way in reminding the programmer/user of how to use the
> function. By "command line parsing" I mean typing 'help(fun)' and
> getting inside the R command window the parsed output of the Rd file
> after stripping of all the markup. Similar to, say, linux man command
> or Matlab/Octave which contains the documentation of the function in
> the first part of the file containing the source code. This way the Rd
> file will be there, so when the author decides that he's ready to
> submit to CRAN he'll have to INSTALL, compile or build the packages it
> will be easier.
>
> But in the long term, I think, it would be natural if pure R would be
> packageable and runnable from within R without any additional platform
> dependent tools. I am moving from Matlab and my m-files basically run
> without modification on both Windows and Linux, save for some system
> dependent commands. It is also quite easy to add/remove a user
> directory of M-files to the Matlab search path. It is not that I am
> recommending or advocating this particular approach for R, but it has
> some attraction as it is quite simple.
>
> I'll follow your advice and I'll see if I'll come up with some useful
> contribution.
>
> Thanks again.
>
> TL
More information about the R-help
mailing list