[Rd] Is it ok to use the name on a bundle and one if its packages?
pgilbert at bank-banque-canada.ca
Fri Mar 12 18:51:57 MET 2004
Henrik Bengtsson wrote:
>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
>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.
>'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
>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
>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
More information about the R-devel