Friedrich Leisch wrote: >>>>>> On Thu, 3 Sep 2009 11:10:31 -0700, >>>>>> Henrik Bengtsson (HB) wrote: > > > On Thu, Sep 3, 2009 at 10:38 AM, Kevin R. > > Coombes<krcoom...@mdacc.tmc.edu> wrote: > >> [1] I agree that sessionInfo() can be taken further. > >> [2] I even more strongly agree that it would be a bad idea to allow > packages > >> to add features that cause the base sessionInfo() function to fail. > >> > >> Why not add an extra function called something like > "packageSessionInfo()" > >> that would provide the desired hooks but keep them from breaking the base > >> functionality? > > > The point is that (if so) there should only be *one function* to call > > for all packages, not one per package, because that would be a pain > > due to dependencies. But, sure I'm happy to start with a > > package[s]SessionInfo() such that > > > c(sessionInfo(), extras=packagesSessionInfo()) > > > pretty much return what I wish. Then it might be easier to argue for > > incorporating the above in sessionInfo() ;) > > > Sorry for not getting it, but I still don't see how adding extra > > information would break the base functionality? Can you give some > > examples? > > > As I said, timeouts can be a problem and possibly also if the hook > > functions have side effects that, say, would load new packages, could > > give funny results, but I also think a package developer who is > > capable to setting up hook function would no how to avoid this. > > > With the default argument of 'extras' to be FALSE, sessionInfo() would > > work as now, with the extra feature that 'extras=TRUE' can give lots > > of additional useful information. > > I think the concept of hook functions for sessionInfo() makes absolute > sense. Yes it should be optional to run them, but the default should > be pkghooks=TRUE, because I don't see why they shouldn't run OK in > 99.9% of all cases. If a hook doesn't run on a certain platform that > would be a bug to me and need to be fixed. Could those who seem to > think such hooks are not a good idea elaborate on what the "danger" > really is?
In Bioconductor sessionInfo() is an essential tool for basic problem diagnosis. Very often the culprit is a mismatch between package versions, which are easy to spot because Bioconductor package versions are incremented with each R release. So a brief sessionInfo() is really good. Also, the typical exchange is 'this is my problem' 'sounds like a package version mismatch, what is your sessionInfo()?' 'this is my sessionInfo()' 'package x is out of date, follow the directions here...' though sometimes the middle two steps are skipped when the user provides sessionInfo up front. Package dependencies in Bioconductor tend to be more complicated than on CRAN, so a user might have a dozen loaded and attached packages. Additional sessionInfo() for each would make it difficult to identify the most common problem (version mismatch). Since issues are usually with only one or two of the packages in the session, custom sessionInfo from all would largely be irrelevant. Since the exchange typically involves a prompt for sessionInfo() from the user, when the initial report hints at problems with a specific package, the initial reply might be 'what is your sessionInfo(packages="LikelyCulprit")?'. There is also a sense in which sessionInfo() provides a useful distinction between 'these things are R's business, to manage the search path, locale, etc' and the business of the package maintainer. Each Bioconductor release cycle involves maintenance of packages to track changes in R. This will be the Achilles heal of package-specific sessionInfo, where a well-meaning developer introduces code that becomes incompatible in a difficult to detect way, and only rears its head at the most important time -- when sessionInfo() would be useful for diagnosis of problems. One not too far-fetched example from a slightly different context was a change in the internal representation of S4 objects that caused some vignettes to print out the entire object (many 100's of pages) rather than the summary intended. Yes these are bugs, and I guess 'package x is producing complete garbage for sessionInfo, likely because your package is out of date. Please update your package and provide sessionInfo again' might well serve to address the user's original problem, but it would have been better to spot the outdated package by looking at the version number produced by sessionInfo(). Martin Morgan > Best, > Fritz > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
