PATCH: Add fields argument to installed.packages and available.packages

"Seth" == Seth Falcon <sfalcon at fhcrc.org>
    on Mon, 28 Aug 2006 17:42:39 -0700 writes:

...

The idea was a field related to but weaker than 'Suggests' :
Something like
    'canMakeUseOf: <pkg1> [, <pkg2>, ... ]
which is *not* used in any QA/QC checking, but is purely
informative: If <pkg1> is require()able, then some examples may
look nicer, a function may provide another feature, etc, etc.
Alternatives to 'canMakeUseOf' would have been
'isHappilyCoworkingWith' ....

What do you (R-devel listeners) think about the idea?
 

Martin

"PaulG" == Paul Gilbert <pgilbert at bank-banque-canada.ca>
    on Tue, 29 Aug 2006 09:55:09 -0400 writes:

"PaulG" == Paul Gilbert <pgilbert at bank-banque-canada.ca>
    on Tue, 29 Aug 2006 09:55:09 -0400 writes:

   PaulG> Martin Maechler wrote:

   >> ...
   >> 
   >> The idea was a field related to but weaker than 'Suggests' :
   >> Something like
   >> 'canMakeUseOf: <pkg1> [, <pkg2>, ... ]
   >> which is *not* used in any QA/QC checking, but is purely
   >> informative: If <pkg1> is require()able, then some examples may
   >> look nicer, a function may provide another feature, etc, etc.
   >> Alternatives to 'canMakeUseOf' would have been
   >> 'isHappilyCoworkingWith' ....
   >> 
   >> What do you (R-devel listeners) think about the idea?

   PaulG> I still like this idea.  I prefer 'canMakeUseOf' to 
   PaulG> 'isHappilyCoworkingWith'  mainly because it seems 
less ambiguous.

Thanks, Paul.
As you may have guessed I should have put a  " :-) "  beside the
'isHappily...' .

Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
is rather too long, but before finding the proper term, we should
agree on usefulness of such a new field.
Apart from the use of package authors {some could note that
other packages make use of theirs, without already depending on
or suggesting them}, it's one of those fields that should help
in the future to explore (e.g. cluster or neighborhood-graph)
the growing high-dimensional space of R packages.

Martin

I like the idea and will look into applying the patch
(note there's at least one typo which makes "make check" fail:
 /priotiry/)

A propos:

A while back (in last summer?), we (some of R-core) have
discussed about a new field to be added to DESCRIPTION,
and AFAIR, the only problem we had, is to find a name we
all liked.
Or was there more then the name alone, and some where convinced
that it is superfluous and hence too complicated.

The idea was a field related to but weaker than 'Suggests' :
Something like
     'canMakeUseOf: <pkg1> [, <pkg2>, ... ]
which is *not* used in any QA/QC checking, but is purely
informative: If <pkg1> is require()able, then some examples may
look nicer, a function may provide another feature, etc, etc.
Alternatives to 'canMakeUseOf' would have been
'isHappilyCoworkingWith' ....

What do you (R-devel listeners) think about the idea?

"Seth" == Seth Falcon <sfalcon at fhcrc.org>
    on Mon, 28 Aug 2006 17:42:39 -0700 writes:

   Seth> Hi all, The write_PACKAGES function has a 'fields'
   Seth> argument that allows a user generating a PACKAGES file
   Seth> to specify additional fields to include.  For
   Seth> symmetry, it would be nice for the available.packages
   Seth> function to be able to read those extra fields when
   Seth> specified.

   Seth> Similarly, it would be useful for installed.packages
   Seth> to have a 'fields' argument.  This would allow a user
   Seth> to query the set of installed packages for other
   Seth> fields in the DESCRIPTION file.

   Seth> One use for this would be for repository hosters to
   Seth> include the License field in their PACKAGES file.  In
   Seth> this way, end users could query a repository and only
   Seth> download packages that they have a license to use.

   Seth> Below is a patch against svn 38996 that attempts to
   Seth> implement this.

I like the idea and will look into applying the patch
(note there's at least one typo which makes "make check" fail:
 /priotiry/)

A propos:

A while back (in last summer?), we (some of R-core) have
discussed about a new field to be added to DESCRIPTION,
and AFAIR, the only problem we had, is to find a name we
all liked.
Or was there more then the name alone, and some where convinced
that it is superfluous and hence too complicated.

The idea was a field related to but weaker than 'Suggests' :
Something like
    'canMakeUseOf: <pkg1> [, <pkg2>, ... ]
which is *not* used in any QA/QC checking, but is purely
informative: If <pkg1> is require()able, then some examples may
look nicer, a function may provide another feature, etc, etc.
Alternatives to 'canMakeUseOf' would have been
'isHappilyCoworkingWith' ....

What do you (R-devel listeners) think about the idea?

Martin

"PaulG" == Paul Gilbert <pgilbert at bank-banque-canada.ca>
    on Tue, 29 Aug 2006 09:55:09 -0400 writes:

    PaulG> Martin Maechler wrote:

    >> ...
    >> 
    >> The idea was a field related to but weaker than 'Suggests' :
    >> Something like
    >> 'canMakeUseOf: <pkg1> [, <pkg2>, ... ]
    >> which is *not* used in any QA/QC checking, but is purely
    >> informative: If <pkg1> is require()able, then some examples may
    >> look nicer, a function may provide another feature, etc, etc.
    >> Alternatives to 'canMakeUseOf' would have been
    >> 'isHappilyCoworkingWith' ....
    >> 
    >> What do you (R-devel listeners) think about the idea?

    PaulG> I still like this idea.  I prefer 'canMakeUseOf' to 
    PaulG> 'isHappilyCoworkingWith'  mainly because it seems less ambiguous.

Thanks, Paul.
As you may have guessed I should have put a  " :-) "  beside the
'isHappily...' .

Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
is rather too long, but before finding the proper term, we should
agree on usefulness of such a new field.
Apart from the use of package authors {some could note that
other packages make use of theirs, without already depending on
or suggesting them}, it's one of those fields that should help
in the future to explore (e.g. cluster or neighborhood-graph)
the growing high-dimensional space of R packages.

I think we need an option to R CMD check rather than a new field in the 
DESCRIPTION.  Currently a package could be mentioned for any of these 
reasons:

1.  To make functions, examples or vignettes work
2.  To allow optional functionality in functions, examples or vignettes.
3.  Because it contains complementary functions.

I don't think we really need to worry about 3:  it should be contained 
in 1 or 2, if reasonably complete examples are given.

Case 1 is handled by Depends.

An author should check case 2 both with and without the suggested 
package.  A user  might be satisfied with a simple check "as things 
currently stand", or might want a stringent check like the author wants. 
  The author can't know that, because it will depend on the user.

So I don't think this is something that should be changed in 
DESCRIPTION.  There should be an option to R CMD check to include or 
exclude packages mentioned in the Suggests entry.  (I'd suggest a 3 
level option:  check as though they are not available, check as 
currently installed, require that they be available.)

Duncan Murdoch <murdoch at stats.uwo.ca> writes:

I think we need an option to R CMD check rather than a new field in the 
DESCRIPTION.  Currently a package could be mentioned for any of these 
reasons:

1.  To make functions, examples or vignettes work
2.  To allow optional functionality in functions, examples or vignettes.
3.  Because it contains complementary functions.

I don't think we really need to worry about 3:  it should be contained 
in 1 or 2, if reasonably complete examples are given.

Case 1 is handled by Depends.

I think there is an important distinction between a dependency needed
for the package to function and a dependency needed to demonstrate
said functionality via an example or vignette.  The former is what
Depends is about, the latter is something else (Suggests).

An author should check case 2 both with and without the suggested 
package.  A user  might be satisfied with a simple check "as things 
currently stand", or might want a stringent check like the author wants. 
  The author can't know that, because it will depend on the user.

So I don't think this is something that should be changed in 
DESCRIPTION.  There should be an option to R CMD check to include or 
exclude packages mentioned in the Suggests entry.  (I'd suggest a 3 
level option:  check as though they are not available, check as 
currently installed, require that they be available.)

I like this approach and agree in general that a solution involving
changes to R CMD check might be the best as opposed to adding fields.

+ seth

On 8/29/2006 10:12 AM, Martin Maechler wrote:

"PaulG" == Paul Gilbert <pgilbert at bank-banque-canada.ca>
    on Tue, 29 Aug 2006 09:55:09 -0400 writes:

    PaulG> Martin Maechler wrote:

    >> ...

    >>     >> The idea was a field related to but weaker than 

'Suggests' :

    >> Something like
    >> 'canMakeUseOf: <pkg1> [, <pkg2>, ... ]
    >> which is *not* used in any QA/QC checking, but is purely
    >> informative: If <pkg1> is require()able, then some examples may
    >> look nicer, a function may provide another feature, etc, etc.
    >> Alternatives to 'canMakeUseOf' would have been
    >> 'isHappilyCoworkingWith' ....

    >>     >> What do you (R-devel listeners) think about the idea?

    PaulG> I still like this idea.  I prefer 'canMakeUseOf' to     
PaulG> 'isHappilyCoworkingWith'  mainly because it seems less ambiguous.

Thanks, Paul.
As you may have guessed I should have put a  " :-) "  beside the
'isHappily...' .

Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
is rather too long, but before finding the proper term, we should
agree on usefulness of such a new field.
Apart from the use of package authors {some could note that
other packages make use of theirs, without already depending on
or suggesting them}, it's one of those fields that should help
in the future to explore (e.g. cluster or neighborhood-graph)
the growing high-dimensional space of R packages.

I think we need an option to R CMD check rather than a new field in 
the DESCRIPTION.  Currently a package could be mentioned for any of 
these reasons:

1.  To make functions, examples or vignettes work
2.  To allow optional functionality in functions, examples or vignettes.
3.  Because it contains complementary functions.

I don't think we really need to worry about 3:  it should be contained 
in 1 or 2, if reasonably complete examples are given.

Case 1 is handled by Depends.

An author should check case 2 both with and without the suggested 
package.  A user  might be satisfied with a simple check "as things 
currently stand", or might want a stringent check like the author 
wants.  The author can't know that, because it will depend on the user.

So I don't think this is something that should be changed in 
DESCRIPTION.  There should be an option to R CMD check to include or 
exclude packages mentioned in the Suggests entry.  (I'd suggest a 3 
level option:  check as though they are not available, check as 
currently installed, require that they be available.)

Duncan Murdoch

Duncan Murdoch wrote:

On 8/29/2006 10:12 AM, Martin Maechler wrote:

"PaulG" == Paul Gilbert <pgilbert at bank-banque-canada.ca>
    on Tue, 29 Aug 2006 09:55:09 -0400 writes:

    PaulG> Martin Maechler wrote:

    >> ...

    >>     >> The idea was a field related to but weaker than 

'Suggests' :

    >> Something like
    >> 'canMakeUseOf: <pkg1> [, <pkg2>, ... ]
    >> which is *not* used in any QA/QC checking, but is purely
    >> informative: If <pkg1> is require()able, then some examples may
    >> look nicer, a function may provide another feature, etc, etc.
    >> Alternatives to 'canMakeUseOf' would have been
    >> 'isHappilyCoworkingWith' ....

    >>     >> What do you (R-devel listeners) think about the idea?

    PaulG> I still like this idea.  I prefer 'canMakeUseOf' to     
PaulG> 'isHappilyCoworkingWith'  mainly because it seems less ambiguous.

Thanks, Paul.
As you may have guessed I should have put a  " :-) "  beside the
'isHappily...' .

Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
is rather too long, but before finding the proper term, we should
agree on usefulness of such a new field.
Apart from the use of package authors {some could note that
other packages make use of theirs, without already depending on
or suggesting them}, it's one of those fields that should help
in the future to explore (e.g. cluster or neighborhood-graph)
the growing high-dimensional space of R packages.

I think we need an option to R CMD check rather than a new field in 
the DESCRIPTION.  Currently a package could be mentioned for any of 
these reasons:

1.  To make functions, examples or vignettes work
2.  To allow optional functionality in functions, examples or vignettes.
3.  Because it contains complementary functions.

I don't think we really need to worry about 3:  it should be contained 
in 1 or 2, if reasonably complete examples are given.

Case 1 is handled by Depends.

Well, from "Writing R Extensions"
   The optional  Suggests  field uses the same syntax as  Depends  and 
lists packages that are not
   necessarily needed. This includes packages used only in examples or 
vignettes

So case 1 is handled by the combination of Depends and Suggests, and we 
need something to handle case 2.

The related question is whether the CRAN checks should  try to check 2, 
or perhaps there needs to be 2a and 2b.  There are cababilities (and 
data) that CRAN may not have, so it would be nice distinguish things 
that should be checked on CRAN from things that should not be.

Paul

An author should check case 2 both with and without the suggested 
package.  A user  might be satisfied with a simple check "as things 
currently stand", or might want a stringent check like the author 
wants.  The author can't know that, because it will depend on the user.

So I don't think this is something that should be changed in 
DESCRIPTION.  There should be an option to R CMD check to include or 
exclude packages mentioned in the Suggests entry.  (I'd suggest a 3 
level option:  check as though they are not available, check as 
currently installed, require that they be available.)

Duncan Murdoch

====================================================================================

La version fran?aise suit le texte anglais.

------------------------------------------------------------------------------------

This email may contain privileged and/or confidential info...{{dropped}}

On 8/29/2006 11:58 AM, Seth Falcon wrote:

I think there is an important distinction between a dependency needed
for the package to function and a dependency needed to demonstrate
said functionality via an example or vignette.  The former is what
Depends is about, the latter is something else (Suggests).

Yes, that's a good point, especially with vignettes.  Only the package
author needs to be able to run them.

But maybe examples should be considered broken if they don't
work. Users should be able to expect example(foo) not to generate an
error.  Package authors should wrap optional examples in code like if
(require(...)).

Duncan Murdoch <murdoch at stats.uwo.ca> writes:
 

On 8/29/2006 11:58 AM, Seth Falcon wrote:
   

I think there is an important distinction between a dependency needed
for the package to function and a dependency needed to demonstrate
said functionality via an example or vignette.  The former is what
Depends is about, the latter is something else (Suggests).
     

Yes, that's a good point, especially with vignettes.  Only the package
author needs to be able to run them.
   

Yes, but just to keep things clear: the value of vignettes is that
users can follow along.  So the ability to programatically identify
the extra required packages is valuable.

 

But maybe examples should be considered broken if they don't
work. Users should be able to expect example(foo) not to generate an
error.  Package authors should wrap optional examples in code like if
(require(...)).
   

I agree.  As with vignettes, there is value in users being able to
follow along and it would be nice to have a programatic way to
identify extra package needed for fancy/involved/optional examples.

Best,

+ seth

Seth Falcon wrote:

Duncan Murdoch <murdoch at stats.uwo.ca> writes:
 

On 8/29/2006 11:58 AM, Seth Falcon wrote:
   

I think there is an important distinction between a dependency needed
for the package to function and a dependency needed to demonstrate
said functionality via an example or vignette.  The former is what
Depends is about, the latter is something else (Suggests).
     

Yes, that's a good point, especially with vignettes.  Only the package
author needs to be able to run them.
   

Yes, but just to keep things clear: the value of vignettes is that
users can follow along.  So the ability to programatically identify
the extra required packages is valuable.

 

But maybe examples should be considered broken if they don't
work. Users should be able to expect example(foo) not to generate an
error.  Package authors should wrap optional examples in code like if
(require(...)).
   

This is a work around that is ok for the developer's testing and to 
prevent failure on CRAN, and I use it. But, other than actually reading 
the examples, it provides no hints to other testers or users about 
things that might be installed, or installed first, to give more 
complete testing and more functionality.

Looking toward the future, I think it would be useful to have a standard 
mechanism to indicate extensions that are available in a package, and 
might be tested and used, but are not necessarily available on CRAN. For 
instance, an example might access to a purchased database or take 
advantage of  a computer cluster. It seems limiting to think that all 
testing that cannot be done on CRAN must be done almost exclusively by 
the developer.

Paul

I agree.  As with vignettes, there is value in users being able to
follow along and it would be nice to have a programatic way to
identify extra package needed for fancy/involved/optional examples.

Best,

+ seth

====================================================================================

La version fran?aise suit le texte anglais.

------------------------------------------------------------------------------------

This email may contain privileged and/or confidential inform...{{dropped}}

On 8/29/2006 2:24 PM, Paul Gilbert wrote:

Seth Falcon wrote:

Duncan Murdoch <murdoch at stats.uwo.ca> writes:
 

On 8/29/2006 11:58 AM, Seth Falcon wrote:
  

I think there is an important distinction between a dependency needed
for the package to function and a dependency needed to demonstrate
said functionality via an example or vignette.  The former is what
Depends is about, the latter is something else (Suggests).
    

Yes, that's a good point, especially with vignettes.  Only the package
author needs to be able to run them.
  

Yes, but just to keep things clear: the value of vignettes is that
users can follow along.  So the ability to programatically identify
the extra required packages is valuable.

 

But maybe examples should be considered broken if they don't
work. Users should be able to expect example(foo) not to generate an
error.  Package authors should wrap optional examples in code like if
(require(...)).
  

This is a work around that is ok for the developer's testing and to 
prevent failure on CRAN, and I use it. But, other than actually 
reading the examples, it provides no hints to other testers or users 
about things that might be installed, or installed first, to give 
more complete testing and more functionality.

I'm not saying to use this instead of Suggests, I'm saying to do both. 
This way the Suggests entries really are suggestions:  the examples 
will run with or without the presence of the suggested packages.

I think there are so many variations on when a Suggested package 
should be installed, that it's not reasonable to expect to be able to 
encode them all in a machine readable way.  They should be documented 
in human readable format.

Looking toward the future, I think it would be useful to have a 
standard mechanism to indicate extensions that are available in a 
package, and might be tested and used, but are not necessarily 
available on CRAN. For instance, an example might access to a 
purchased database or take advantage of  a computer cluster. It seems 
limiting to think that all testing that cannot be done on CRAN must 
be done almost exclusively by the developer.

If by "mechanism" you mean human-readable documentation, I agree with 
this.

Duncan Murdoch

Paul

I agree.  As with vignettes, there is value in users being able to
follow along and it would be nice to have a programatic way to
identify extra package needed for fancy/involved/optional examples.

Best,

+ seth

==================================================================================== 


La version fran?aise suit le texte anglais.

------------------------------------------------------------------------------------ 


This email may contain privileged and/or confidential 
inform...{{dropped}}

Duncan Murdoch wrote:

On 8/29/2006 2:24 PM, Paul Gilbert wrote:

Seth Falcon wrote:

Duncan Murdoch <murdoch at stats.uwo.ca> writes:
 

On 8/29/2006 11:58 AM, Seth Falcon wrote:
  

I think there is an important distinction between a dependency needed
for the package to function and a dependency needed to demonstrate
said functionality via an example or vignette.  The former is what
Depends is about, the latter is something else (Suggests).
    

Yes, that's a good point, especially with vignettes.  Only the package
author needs to be able to run them.
  

Yes, but just to keep things clear: the value of vignettes is that
users can follow along.  So the ability to programatically identify
the extra required packages is valuable.

 

But maybe examples should be considered broken if they don't
work. Users should be able to expect example(foo) not to generate an
error.  Package authors should wrap optional examples in code like if
(require(...)).
  

This is a work around that is ok for the developer's testing and to 
prevent failure on CRAN, and I use it. But, other than actually 
reading the examples, it provides no hints to other testers or users 
about things that might be installed, or installed first, to give 
more complete testing and more functionality.

I'm not saying to use this instead of Suggests, I'm saying to do both. 
This way the Suggests entries really are suggestions:  the examples 
will run with or without the presence of the suggested packages.

I think there are so many variations on when a Suggested package 
should be installed, that it's not reasonable to expect to be able to 
encode them all in a machine readable way.  They should be documented 
in human readable format.

Looking toward the future, I think it would be useful to have a 
standard mechanism to indicate extensions that are available in a 
package, and might be tested and used, but are not necessarily 
available on CRAN. For instance, an example might access to a 
purchased database or take advantage of  a computer cluster. It seems 
limiting to think that all testing that cannot be done on CRAN must 
be done almost exclusively by the developer.

If by "mechanism" you mean human-readable documentation, I agree with 
this.

Yes,  I was think of human-readable and in a standard location, like a 
field in the DESCRIPTION file.  (You are thinking of fields in the 
DESCRIPTION file as human-readable, are you not?)

Paul

Duncan Murdoch

Paul

I agree.  As with vignettes, there is value in users being able to
follow along and it would be nice to have a programatic way to
identify extra package needed for fancy/involved/optional examples.

Best,

+ seth

==================================================================================== 


La version fran?aise suit le texte anglais.

------------------------------------------------------------------------------------ 


This email may contain privileged and/or confidential 
inform...{{dropped}}

====================================================================================

La version fran?aise suit le texte anglais.

------------------------------------------------------------------------------------

This email may contain privileged and/or confidential info...{{dropped}}

On 8/29/2006 4:13 PM, Paul Gilbert wrote:

Duncan Murdoch wrote:

This doesn't address the problem of someone who hasn't got the package
installed yet, though perhaps CRAN could put a version of that man page
(or all of them) online for browsing.  Unfortunately this hasn't
happened yet, but maybe we'll get to it before 2.5.0.

Duncan Murdoch <murdoch at stats.uwo.ca> writes:

I think we need an option to R CMD check rather than a new field in the
DESCRIPTION.  Currently a package could be mentioned for any of these
reasons:

1.  To make functions, examples or vignettes work
2.  To allow optional functionality in functions, examples or vignettes.
3.  Because it contains complementary functions.

I don't think we really need to worry about 3:  it should be contained
in 1 or 2, if reasonably complete examples are given.

Case 1 is handled by Depends.

I think there is an important distinction between a dependency needed
for the package to function and a dependency needed to demonstrate
said functionality via an example or vignette.  The former is what
Depends is about, the latter is something else (Suggests).

Duncan Murdoch writes:

On 8/29/2006 10:12 AM, Martin Maechler wrote:

"PaulG" == Paul Gilbert <pgilbert at bank-banque-canada.ca>
on Tue, 29 Aug 2006 09:55:09 -0400 writes:

...

The idea was a field related to but weaker than 'Suggests' :
Something like
'canMakeUseOf: <pkg1> [, <pkg2>, ... ]
which is *not* used in any QA/QC checking, but is purely
informative: If <pkg1> is require()able, then some examples may
look nicer, a function may provide another feature, etc, etc.
Alternatives to 'canMakeUseOf' would have been
'isHappilyCoworkingWith' ....

What do you (R-devel listeners) think about the idea?

Thanks, Paul.
As you may have guessed I should have put a  " :-) "  beside the
'isHappily...' .

Of course, even 'CanMakeUseOf' {we should capitalize the first letter}
is rather too long, but before finding the proper term, we should
agree on usefulness of such a new field.
Apart from the use of package authors {some could note that
other packages make use of theirs, without already depending on
or suggesting them}, it's one of those fields that should help
in the future to explore (e.g. cluster or neighborhood-graph)
the growing high-dimensional space of R packages.

I think we need an option to R CMD check rather than a new field in the 
DESCRIPTION.  Currently a package could be mentioned for any of these 
reasons:

1.  To make functions, examples or vignettes work
2.  To allow optional functionality in functions, examples or vignettes.
3.  Because it contains complementary functions.

I don't think we really need to worry about 3:  it should be contained 
in 1 or 2, if reasonably complete examples are given.

Case 1 is handled by Depends.

An author should check case 2 both with and without the suggested 
package.  A user  might be satisfied with a simple check "as things 
currently stand", or might want a stringent check like the author wants. 
  The author can't know that, because it will depend on the user.

So I don't think this is something that should be changed in 
DESCRIPTION.  There should be an option to R CMD check to include or 
exclude packages mentioned in the Suggests entry.  (I'd suggest a 3 
level option:  check as though they are not available, check as 
currently installed, require that they be available.)

"FrL" == friedrich leisch <friedrich.leisch at stat.uni-muenchen.de>
    on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:

Martin Maechler writes:

"FrL" == friedrich leisch <friedrich.leisch at stat.uni-muenchen.de>
    on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:

Duncan Murdoch <murdoch at stats.uwo.ca> writes:

I think we need an option to R CMD check rather than a new field in the
DESCRIPTION.  Currently a package could be mentioned for any of these
reasons:

1.  To make functions, examples or vignettes work
2.  To allow optional functionality in functions, examples or vignettes.
3.  Because it contains complementary functions.

I don't think we really need to worry about 3:  it should be contained
in 1 or 2, if reasonably complete examples are given.

Case 1 is handled by Depends.

I think there is an important distinction between a dependency needed
for the package to function and a dependency needed to demonstrate
said functionality via an example or vignette.  The former is what
Depends is about, the latter is something else (Suggests).

...

Further, I think "2)" above is not taken care of anyway.
After all the interesting statements and alternative proposals,
I'm still proposing to introduce a  'canUse'  field for DESCRIPTION
which
  a) has a "human-readable intent" of being weaker than 'Suggests'
  b) will not require its packages to be available for R CMD check
  c) conveys extra information about the package's context, to humans, and
  d) will potentially be used in automated or semi-manual 
     ``R package database management''

On 8/29/2006 4:13 PM, Paul Gilbert wrote:

Duncan Murdoch wrote:

[...]

This doesn't address the problem of someone who hasn't got the package
installed yet, though perhaps CRAN could put a version of that man page
(or all of them) online for browsing.  Unfortunately this hasn't
happened yet, but maybe we'll get to it before 2.5.0.

The help pages are available on CRAN in PDF format, if there are strong
preferences to also get the HTML version online that should not be a major
problem.

On 8/30/2006 3:21 AM, friedrich.leisch at stat.uni-muenchen.de wrote:

On 8/29/2006 4:13 PM, Paul Gilbert wrote:

Duncan Murdoch wrote:

[...]

This doesn't address the problem of someone who hasn't got the package
installed yet, though perhaps CRAN could put a version of that man page
(or all of them) online for browsing.  Unfortunately this hasn't
happened yet, but maybe we'll get to it before 2.5.0.

The help pages are available on CRAN in PDF format, if there are strong
preferences to also get the HTML version online that should not be a
major
problem.

Just to clarify: "this hasn't happened yet" was meant to apply to the
earlier part of my message, the changes necessary to make the package
man page easier to maintain.

"FrL" == friedrich leisch <friedrich.leisch at stat.uni-muenchen.de>
    on Wed, 30 Aug 2006 09:34:13 +0200 (MEST) writes:

    >> Duncan Murdoch <murdoch at stats.uwo.ca> writes:

    >>> I think we need an option to R CMD check rather than a new field

in the

    >>> DESCRIPTION.  Currently a package could be mentioned for any of

these

    >>> reasons:
    >>>
    >>> 1.  To make functions, examples or vignettes work
    >>> 2.  To allow optional functionality in functions, examples or

vignettes.

    >>> 3.  Because it contains complementary functions.
    >>>
    >>> I don't think we really need to worry about 3:  it should be

contained

    >>> in 1 or 2, if reasonably complete examples are given.
    >>>
    >>> Case 1 is handled by Depends.

    >>
    >> I think there is an important distinction between a dependency

needed

    >> for the package to function and a dependency needed to demonstrate
    >> said functionality via an example or vignette.  The former is what
    >> Depends is about, the latter is something else (Suggests).

    FrL> Sorry to join in late, I am at the Compstat conference and have
limited
    FrL> email access. What Seth describes in the above paragraph is
exactly what I
    FrL> had in mind when splitting the single Depends field we had into
Depends
    FrL> and Suggests: Depends are a necessity to run the package,
Suggests is nice
    FrL> to have but not necessary. If you know how to use a package you
may the
    FrL> decide not to install a package that is only suggested, but

    FrL> * may not be interested to execute the examples,
    FrL> * know that you never need the extra functionality
    FrL> * ...

    FrL> so it should not be auto-installed unless you ask for
    FrL> it (the default could also be the other way round, the
    FrL> point is that it should be possible to have package foo
    FrL> but not the packages it only suggests). On CRAN we
    FrL> check with all suggestions to test all bits and pieces,
    FrL> having an option in R CMD check to test only with
    FrL> suggests may be nice, if there is use for it.

Yes.
However, I see two (related) problems with the current 'Suggests'
and that's why I opened this thread proposing to have a
(what I now would want to simply call)  'canUse' :

1) For 'R CMD check' (and hence CRAN checking),
   Packages in 'Suggests' must be require()able, and
   hence all testing only happens *with* the suggested packages
   being there, and not without.

2) "Suggests"  suggests to the human reader of DESCRIPTION that
   the package authors suggest to also install the packages listed
   there.
   Now there are cases, I (as package author) want to show some
   stuff, or even provide compatibility functionality for some
   packages that are related to mine, but which I really do not
``suggest''
   to also be installed, e.g., because the other packages do
   similar stuff as mine, but I believe my package to be
   superior.  In such a case, I may, e.g., want to provide
   functions for porting the other package classes to my package's.

Duncan Murdoch has proposed to take care of "1)" by
still only use 'Suggests' but adding another option to 'R CMD
check', let's say   --no-suggests  which would run all the
checks without having the suggested packages available
--- something not quite easy to implement, BTW:
Imagine the typical windows users who (AFAICS) always only use
one library into which they install all packages.
How do you want the
    if( require(<my_suggested_package>) ) {
       ...
    }
clause *not* to be triggered in such a case ?
I do agree quite a bit that such a '--no-suggests' option would
be very useful for 'R CMD check' -- in addition to my proposal.

Further, I think "2)" above is not taken care of anyway.
After all the interesting statements and alternative proposals,
I'm still proposing to introduce a  'canUse'  field for DESCRIPTION
which
  a) has a "human-readable intent" of being weaker than 'Suggests'
  b) will not require its packages to be available for R CMD check
  c) conveys extra information about the package's context, to humans, and
  d) will potentially be used in automated or semi-manual
     ``R package database management''