From mtmorgan at fhcrc.org  Fri Sep  4 16:50:25 2009
From: mtmorgan at fhcrc.org (Martin Morgan)
Date: Fri, 04 Sep 2009 07:50:25 -0700
Subject: [Rd] Suggestion: Allow packages to add additional	information
 to sessionInfo()
In-Reply-To: <19104.55316.569815.523978@ridcully.stat.uni-muenchen.de>
References: <59d7961d0909031005p676b5fe8m4878c1149c22dad6@mail.gmail.com>	<971536df0909031016t2658cc1dl98c11d597cb3066c@mail.gmail.com>	<59d7961d0909031027t5ec2d0f5u707a140dcd3d6474@mail.gmail.com>	<4A9FFF14.8010800@mdacc.tmc.edu>	<59d7961d0909031110w64b2df4en48e99c8ea5aeca1e@mail.gmail.com>
	<19104.55316.569815.523978@ridcully.stat.uni-muenchen.de>
Message-ID: <4AA12931.9030703@fhcrc.org>

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<krcoombes at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] Suggestion: Allow packages to add additional information to sessionInfo()
Martin Morgan