I'm planning on adding some new WebGL functionality to the rgl package, but it will pull in a very large number of dependencies. Since many people won't need it, I'd like to make the new parts optional. The general idea I'm thinking of is to put the new stuff into a separate package, and have rgl "Suggest" it. But I'm not sure whether these functions should only be available in the new package (so users would have to attach it to use them), or whether they should be in rgl, but fail if the new package is not available for loading. Can people suggest other packages that solve this kind of problem in a good way? Duncan Murdoch
On Thu, 2015-10-22 at 15:55 -0400, Duncan Murdoch wrote:> I'm planning on adding some new WebGL functionality to the rgl package, > but it will pull in a very large number of dependencies. Since many > people won't need it, I'd like to make the new parts optional. > > The general idea I'm thinking of is to put the new stuff into a separate > package, and have rgl "Suggest" it. But I'm not sure whether these > functions should only be available in the new package (so users would > have to attach it to use them), or whether they should be in rgl, but > fail if the new package is not available for loading. > > Can people suggest other packages that solve this kind of problem in a > good way?We have a number of functions in PerformanceAnalytics or PortfolioAnalytics that rely on packages in 'Suggests'. The model we have chiefly used is stopifnot("package:MASS" %in% search() || require("MASS",quietly=TRUE)) of course, it is now no longer recommended to do it this way, so we'll probably need to test and load namespaces instead. It makes sense to me to have such functions in the main package, and provide pointers in the documentation and the error message which describe that the other package is required to be available for the function to work. Regards, Brian -- Brian G. Peterson http://braverock.com/brian/ Ph: 773-459-4973 IM: bgpbraverock
On 22 October 2015 at 15:08, Brian G. Peterson wrote:
| On Thu, 2015-10-22 at 15:55 -0400, Duncan Murdoch wrote:
| > I'm planning on adding some new WebGL functionality to the rgl
package,
| > but it will pull in a very large number of dependencies. Since many
| > people won't need it, I'd like to make the new parts optional.
| >
| > The general idea I'm thinking of is to put the new stuff into a
separate
| > package, and have rgl "Suggest" it. But I'm not sure
whether these
| > functions should only be available in the new package (so users would
| > have to attach it to use them), or whether they should be in rgl, but
| > fail if the new package is not available for loading.
| >
| > Can people suggest other packages that solve this kind of problem in a
| > good way?
|
| We have a number of functions in PerformanceAnalytics or
| PortfolioAnalytics that rely on packages in 'Suggests'.
|
| The model we have chiefly used is
|
| stopifnot("package:MASS" %in% search() ||
require("MASS",quietly=TRUE))
|
| of course, it is now no longer recommended to do it this way, so we'll
| probably need to test and load namespaces instead.
|
| It makes sense to me to have such functions in the main package, and
| provide pointers in the documentation and the error message which
| describe that the other package is required to be available for the
| function to work.
Rcmdr by John Fox has also done this for many years -- and has also moved
back from "everything in Depends (or Imports)" to "most things in
Suggests".
As I maintain the package in Debian I had to add a fair number of packages
because the requirement was "hard" (via Depends/Imports) so that the
extra
package was needed to actually start Rcmdr.
Generally, a soft requirement is much better, especially when coupled with
appropriate tests -- eg via requireNamespace("packageName",
quietly=TRUE) --
and this can be coupled with notifying the user about the optional package.
Also note that CRAN got itself a new Repo Policy revision where this was added:
A package listed in `Suggests' or `Enhances' should be used
conditionally in examples or tests if it cannot straightforwardly be
installed on the major R platforms.
This is step forward as it recognises that Suggests: need to be tested for.
Sadly it still waters it down via the "not straightforwardly". But
then Rome
wasn't built with a single Policy Revision either ...
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
On 10/22/2015 03:55 PM, Duncan Murdoch wrote:> I'm planning on adding some new WebGL functionality to the rgl package, > but it will pull in a very large number of dependencies. Since many > people won't need it, I'd like to make the new parts optional. > > The general idea I'm thinking of is to put the new stuff into a separate > package, and have rgl "Suggest" it. But I'm not sure whether these > functions should only be available in the new package (so users would > have to attach it to use them), or whether they should be in rgl, but > fail if the new package is not available for loading. > > Can people suggest other packages that solve this kind of problem in a > good way?I do something similar in several packages. I would distinguish between the situation where the new functions have some functionality without all the extra dependencies, and the case where they really do not. In the former case it makes sense to put the functions in rgl and then fail when the extra functionality is demanded and not available. In the latter case, it "feels like" you are trying to defeat Depends: or Imports:. That route has usually gotten me in trouble. Another thing you might want to consider is that, at least for awhile, the new functions in rglPlus will probably be less stable then those in rgl. Being able to change those and update rglPlus without needing to update rgl can be a real advantage (i.e. if the API for the new functions is in rgl, and you need to change it, then you are required to notify all the package maintainers that depend on rgl, do reverse testing, and you have to explain that your update of rgl is going to break rglPlus and you have a new version of that but you cannot submit that yet because it will not work until the new rgl is in place.) Paul> > Duncan Murdoch > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
On Thu, Oct 22, 2015 at 3:48 PM, Paul Gilbert <pgilbert902 at gmail.com> wrote:> > > On 10/22/2015 03:55 PM, Duncan Murdoch wrote: >> >> I'm planning on adding some new WebGL functionality to the rgl package, >> but it will pull in a very large number of dependencies. Since many >> people won't need it, I'd like to make the new parts optional. >> >> The general idea I'm thinking of is to put the new stuff into a separate >> package, and have rgl "Suggest" it. But I'm not sure whether these >> functions should only be available in the new package (so users would >> have to attach it to use them), or whether they should be in rgl, but >> fail if the new package is not available for loading. >> >> Can people suggest other packages that solve this kind of problem in a >> good way? > > > I do something similar in several packages. I would distinguish between the > situation where the new functions have some functionality without all the > extra dependencies, and the case where they really do not. In the former > case it makes sense to put the functions in rgl and then fail when the extra > functionality is demanded and not available. In the latter case, it "feels > like" you are trying to defeat Depends: or Imports:. That route has usually > gotten me in trouble. > > Another thing you might want to consider is that, at least for awhile, the > new functions in rglPlus will probably be less stable then those in rgl. > Being able to change those and update rglPlus without needing to update rgl > can be a real advantage (i.e. if the API for the new functions is in rgl, > and you need to change it, then you are required to notify all the package > maintainers that depend on rgl, do reverse testing, and you have to explain > that your update of rgl is going to break rglPlus and you have a new version > of that but you cannot submit that yet because it will not work until the > new rgl is in place.)I favor the latter solution; keep rgl as a core package and add bells and whistles to rglPlus and have rglPlus attach rgl so that people using the extra functions can just do library(rglPlus). This way rgl does not have to "know about" rglPlus. Not sure if this design is possible, or rgl do need to have to know about rglPlus. /Henrik> > Paul > >> >> Duncan Murdoch >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel
On 22 October 2015 at 22:55, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:> I'm planning on adding some new WebGL functionality to the rgl package, but > it will pull in a very large number of dependencies. Since many people won't > need it, I'd like to make the new parts optional.> Can people suggest other packages that solve this kind of problem in a good > way?I had the same issue with the assertive package: it was getting big, and not everyone wanted all the functionality. The solution was to create several smaller packages with individual components of functionality, for example assertive.base contains the bare-minimum functionality; assertive.numbers contains functionality related to numbers, etc. Then the assertive package imports all the functions from the component packages and reexports them. That way people who want a small footprint (mostly other package developers) can specify only what they need, and people who don't care (mostly end users) can just type library(assertive) and get access to everything. -- Regards, Richie Learning R 4dpiecharts.com
On 16/11/2015 4:00 AM, Richard Cotton wrote:> On 22 October 2015 at 22:55, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >> I'm planning on adding some new WebGL functionality to the rgl package, but >> it will pull in a very large number of dependencies. Since many people won't >> need it, I'd like to make the new parts optional. > >> Can people suggest other packages that solve this kind of problem in a good >> way? > > I had the same issue with the assertive package: it was getting big, > and not everyone wanted all the functionality. > > The solution was to create several smaller packages with individual > components of functionality, for example assertive.base contains the > bare-minimum functionality; assertive.numbers contains functionality > related to numbers, etc. > > Then the assertive package imports all the functions from the > component packages and reexports them. > > That way people who want a small footprint (mostly other package > developers) can specify only what they need, and people who don't care > (mostly end users) can just type library(assertive) and get access to > everything. >When you import and re-export functions, do they need to be documented in both places? I forget if we have a simple way to say "this function is documented in that package", to avoid duplication. Duncan Murdoch