[Bioc-devel] Sweave changes (keep.source = TRUE or FALSE?)

Friedrich Leisch Friedrich.Leisch at stat.uni-muenchen.de
Fri Dec 8 17:03:58 CET 2006


I must apologize, the wording that "I got only one serious email" was
not appropriate (but reflects how I perceived the discussion up to
that point).  From my point of view the situation looked/looks as

(0) This whole discussion happens for me at a very bad point in time
    due to very limited time, hence delays in aswering emails (because I
    did carefully think about each proposal I made).

(1) I personally think that R code I write is well-idented and
    formatted and I never liked Sweave to reformat my sources.

(2) Over the years I have answered dozens of "bug reports" in private
    emails why Sweave discards comments and reformats the sources to
    people to lazy to read the FAQ.

(3) Finally, Duncan implements a solution to the problem, I expect him
    to get praised for it, and what happens is a flame war.

(4) Perhaps I should have read more carefully between the lines of
    some emails (but see (0)), but the basic tone was [ATTENTION,
    EXAGGARATION, i don't want to insult anybody, just set the picture
    ]: "you can't do that because we would have to insert one line in
    each of our documents. We know how to write complicated software to
    analzye microarrays, but not how to automate that task."

So all of R is allowed to improve and change all the time, but here is
exception? Why? [Email continued below]

>>>>> On Thu, 7 Dec 2006 12:00:44 -0500 (EST),
>>>>> Vincent Carey 525-2265 (VC5) wrote:

  >> Note: I got only one serious email (the one by Deepayan I'll answer in
  >> a minute) that keep.source=FALSE produces better looking documents in
  >> some cases, and that's a discussion I like.  All other complaints
  >> where simply of the form "we can't change it because it has always
  >> been the way that it is". I thought that rule is not necessarily true
  >> in a research project like R.

  > I don't accept the caricature here.  People can disagree on what
  > a good default setting is, and, apparently, even what a bug is.

Yes, and if the reactions would have been formulated like that, I
would have responded differently. But the first reactions were "you
can't do that, because it means work for us." [repeated several times
and not exactly silently].

  > I would never have regarded the use of R deparse formatting by
  > Sweave as a bug -- that just tells you how messy my sources are.
  > I can pay the price of setting an option if you want to remove the
  > role of deparse in code formatting.  But I wanted you alert you to
  > an alternative attitude about it, which includes reckoning with
  > the possibility that things may look a lot worse in a lot of
  > default-processed documents, both those written in the past and
  > those to be written, when the default is changed.  That
  > possibility may also be dismissed, but it is not a conservative
  > complaint, and it does provide a basis for thinking about the
  > purpose of a default setting.

  > No one challenged the introduction of the new functionality.  The
  > initial justification for the alteration of the default included
  > the desire to get more information on possible problems with the
  > new keep.source functionality in connection with Sweave.  I found
  > that somewhat annoying -- yes, it will generate data on possible
  > problems, but at substantial cost to users, or maybe just to our
  > project.  So I think there was a basis for objection to the
  > altered default, but one that could be discussed.  I recognize
  > that R-devel is unstable and experimental, but there is still a
  > role for some pushback, and the core can choose to disregard it if
  > the benefits of the change outweigh the costs.

I fully agree here, but there must be arguments why the change should
not be made, and the argument cannot be "we have to adapt 200 files"
(when the change can be done in a 3 line R/sed/perl/whatever script

  > I was completely mystified by the transition from a
  > default setting for a code formatting process to considerations of
  > central configuration files or flavors of R.  But maybe that reflects
  > my limitations more than anything else.  I think this issue is very
  > local to a feature of a specific piece of software and should have no
  > broad ramifications for the general installation process or
  > distribution/installation of R.

Well, I don't like to fix a problem locally for one particular aspect
of the distribution process. If building of vignettes should be
configurable for a project, so should the rest of the build process
(and vice versa). Anything else is hard to maintain and not
transparent to users.


PS: At least from my point of view the discussion since my last couple
of emails email was much more focused on pros and cons rather than
simple "I don't want that!!!" statments, hence perhaps it needs some
caricature from time to time ... ;-)

More information about the Bioc-devel mailing list