[Rd] Is it ok to use the name on a bundle and one if its packages?

[Paul Gilbert]

Henrik Bengtsson wrote:

>Hello,
>
>I wonder if it is unwise to name a bundle the same as one of its
>packages. For instance, I now have a huge package called 'aroma' that
>I basically want to split up in several smaller packages, say
>'aroma.core', 'aroma.io', 'aroma.explore', 'aroma.trial',
>'aroma.deprecated' etc, which simplifies maintenance but also the
>overview. For convenience, one could have a wrapper package
>'aroma.all' that loads all the above packages. 
>
>As a typically user will make use of methods in the, say, three
>packages 'aroma.core', 'aroma.io' and 'aroma.explore' I would also
>like to have a wrapper package that loads these three "typical"
>packages. This package I would like to call 'aroma', just like the
>bundle. Is this wise, or should I rename the bundle to say 'AROMA'? 
>
I'm not sure if there would be problems. I have  one of the few bundles 
that exist, and I as far as I know, no one has tried this. (I would find 
it a bit confusing myself.) If the packages have a hierarchy, then you 
can get the behavior you want just by having require("whatever") in the 
start up for each package. So, for example, if aroma.explore  needs 
aroma.core and aroma.io, the  .First.lib for aroma.explore can have 
lines require("aroma.core"); require("aroma.io"). Then users would just 
load the highest package they need in the hierarchy.

>
>I would prefer that the user could install the bundle by
>
>  install.packages("aroma")
>
>without having to care if I distribute the methods in one package
>called 'aroma' or bundle of packages called 'aroma'. 
>
I don't think there is a problem here.

>Moreover,
>'library(aroma)' will also do for the typical user too. 
>
This could be a problem that your idea may work around, but you may be 
creating more confusion than help. If the set of functions that are 
being loaded changes, then it is not such a bad idea to change the name.

>To turn it
>around, what I'm trying to do is to emulate the concept of
>"subpackages".
>
>Another advantage is that if you first start out with a package
>'aroma' that people installs, then you can without having to tell the
>users, change it to be a bundle. 'update.package()' will still work;
>
It is possible your suggestion would make this work better than it works 
if you avoid having a subpackage with the same name as the bundle. 
Without replicating the name in a package of the bundle, the update of 
the bundle may leave the original "aroma" package in place. That would 
not be good.

>Same if you want to revert to a package. I haven't tested if it works
>in practice, though. 
>
There may be problems here. I don't think the packages of the bundle 
would be removed, and that would cause users a certain amount of confusion.

>
>BTW: I remember reading some r-help/r-devel(?) comments about not
>supporting bundles in the future and just keeping the concept of
>packages. Is this something that should we expected to happen?
>Personally I think a bundle is a convenient way to distribute packages
>that are used together, but not necessarily loaded at the same time.
>
The mechanism works very well right now, but there are not many of us 
using it. I am moving more toward unbundling myself (because my package 
hierarchy is changing with additional packages, not because of any 
problems).

Paul Gilbert

>
>Best wishes
>
>Henrik Bengtsson
>
>Dept. of Mathematical Statistics @ Centre for Mathematical Sciences
>Lund Institute of Technology/Lund University, Sweden 
>(Sweden +1h UTC, Melbourne +11 UTC, Calif. -8h UTC)
>+46 708 909208 (cell), +46 46 320 820 (home), 
>+1 (508) 464 6644 (global fax),
>+46 46 2229611 (off), +46 46 2224623 (dept. fax)
>h b @ m a t h s . l t h . s e, http://www.maths.lth.se/~hb/
>
>______________________________________________
>R-devel at stat.math.ethz.ch mailing list
>https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
>
>  
>