Re: [Rd] Problem understanding behaviour of versionCheck for loadNamespace (and when versions for Imports packages are checked)
Hi Duncan
The difference is that in your call to loadNamespace, the versionCheck list
has 3 components (name, op and version), whereas the documentation only
mentions 2 (op and version).
loadNamespace 'works' for me provided I add a third component to the list
(even a nonsense one).
What I haven't yet had the fortitude to do is track down through the code to
see what the arguments are (ie how many elements there are in the
versionCheck list) to any calls to loadNamespace that are generated
internally when the Imports to package2 are being loaded (either because
they are explicitly mentioned in the NAMESPACE file, or because they are
invoked by a "importedpackage1::fun_from_imported_package1" line of code).
I'll put a bug report together later today, and include my toy packages etc.
Once again thanks for looking at this for me
Geoff
-Original Message-
From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
Sent: Thursday, 27 November 2014 12:09 PM
To: Geoff Lee; r-devel@r-project.org
Subject: Re: [Rd] Problem understanding behaviour of versionCheck for
loadNamespace (and when versions for Imports packages are checked)
On 26/11/2014, 7:38 PM, Geoff Lee wrote:
> Many thanks Duncan for the quick response.
A little too quick, it seems...
>
> A bug is a relief in a way. I've been digging my way deeper into this
> (and learning more as I go) for several days now - but it is a
> diversion from (a diversion from) my main goal :-(
>
> Is there somewhere specific I should report or log the bug or will
> that happen from this mailing-list automatically? (I have seen the Bug
> Tracking link on the r-project page and followed that, but don't yet
> have a Bugzilla account, nor know the precise mechanics and protocols
> for notifying a bug)
If you can put together a simple set of steps to illustrate a bug, then
reporting on bugs.r-project.org is the way to get it recorded.
Reporting it on this list is really hit and miss. But I think from your
previous description, something else is going on. When I try to load a
namespace with a bad version number, I get an error:
loadNamespace("rgl", versionCheck=list(name="rgl", op=">",
version=package_version('3.0')))
Error in loadNamespace("rgl", versionCheck = list(name = "rgl", op = ">", :
namespace 'rgl' 0.95.1163 is being loaded, but > 3.0 is required
Duncan Murdoch
>
> Geoff
>
> PS Building package2 - via devtools::build('package2', binary = TRUE)
> does check and insist that I have an appropriate version of the 'to be
imported'
> package1 installed in my .libPath().
>
> It was only when I simulated a user who has and older version of the
> Imported package1 (by overwriting the later version of package 1 with
> an earlier version), then trying to load or attach package2 that the
> (failure of the version checking) at loadNamespace time for package1
> became apparent (well apparentish after quite a bit of digging)
>
> -Original Message-
> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> Sent: Thursday, 27 November 2014 10:57 AM
> To: Geoff Lee; r-devel@r-project.org
> Subject: Re: [Rd] Problem understanding behaviour of versionCheck for
> loadNamespace (and when versions for Imports packages are checked)
>
> Summary: I think you've found a bug.
>
> On 26/11/2014, 5:39 PM, Geoff Lee wrote:
>> Hi
>>
>>
>>
>> I'm still exploring the R programming universe, so if this is being
>> asked in the wrong place, or in the wrong way (e.g. too verbose or
>> lacking in crucial detail or in the wrong format) please let me know
>>
>>
>>
>> I am trying to understand when the version constraints for packages
>> which appear in the Imports field of a DESCRIPTION file are checked.
>
> I would have assumed they are checked when you try to install the package.
> If you ask for version 3.0, and only have 0.3, the install should fail.
>
> But as you've found, the documents say something else...
>
>>
>>
>>
>> Along the way I've hit a snag understanding what loadNamespace with
>> the versionCheck argument set does. The core of my query is 'am I
>> doing something wrong, or have I stumbled across a bug?'. Probably
>> the former, but after several days I still can't figure it out, so
>> any guidance, hints or outright help would be much appreciated.
>>
>>
>>
>> Thanks in advance
>>
>>
>>
>> Geoff
>>
>>
>>
>> What I've tried so far.
>>
>>
>>
>> "Writing R extensions" section 1.1.3 says
>>
>>
>>
>> "The 'Imports' field lists packages whose namespaces are imported
>> from (as specified in the NAMESPACE file) but which do not need to be
attached.
> ...
>> shortened for brevity ... Packages declared in the 'Depends' field
>> should not also be in the 'Imports' field. Version requirements can
>> be specified and are checked when the namespace is loaded (since R >=
3.0.0).
> "
>>
>>
>>
>> It is slightly ambiguous, but seems to mean that the version
>> dependencies for both Depends packages and Imports packages are
>>
Re: [Rd] Problem understanding behaviour of versionCheck for loadNamespace (and when versions for Imports packages are checked)
Many thanks Duncan for the quick response.
A bug is a relief in a way. I've been digging my way deeper into this (and
learning more as I go) for several days now - but it is a diversion from (a
diversion from) my main goal :-(
Is there somewhere specific I should report or log the bug or will that
happen from this mailing-list automatically? (I have seen the Bug Tracking
link on the r-project page and followed that, but don't yet have a Bugzilla
account, nor know the precise mechanics and protocols for notifying a bug)
Geoff
PS Building package2 - via devtools::build('package2', binary = TRUE) does
check and insist that I have an appropriate version of the 'to be imported'
package1 installed in my .libPath().
It was only when I simulated a user who has and older version of the
Imported package1 (by overwriting the later version of package 1 with an
earlier version), then trying to load or attach package2 that the (failure
of the version checking) at loadNamespace time for package1 became apparent
(well apparentish after quite a bit of digging)
-Original Message-
From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
Sent: Thursday, 27 November 2014 10:57 AM
To: Geoff Lee; r-devel@r-project.org
Subject: Re: [Rd] Problem understanding behaviour of versionCheck for
loadNamespace (and when versions for Imports packages are checked)
Summary: I think you've found a bug.
On 26/11/2014, 5:39 PM, Geoff Lee wrote:
> Hi
>
>
>
> I'm still exploring the R programming universe, so if this is being
> asked in the wrong place, or in the wrong way (e.g. too verbose or
> lacking in crucial detail or in the wrong format) please let me know
>
>
>
> I am trying to understand when the version constraints for packages
> which appear in the Imports field of a DESCRIPTION file are checked.
I would have assumed they are checked when you try to install the package.
If you ask for version 3.0, and only have 0.3, the install should fail.
But as you've found, the documents say something else...
>
>
>
> Along the way I've hit a snag understanding what loadNamespace with
> the versionCheck argument set does. The core of my query is 'am I
> doing something wrong, or have I stumbled across a bug?'. Probably
> the former, but after several days I still can't figure it out, so any
> guidance, hints or outright help would be much appreciated.
>
>
>
> Thanks in advance
>
>
>
> Geoff
>
>
>
> What I've tried so far.
>
>
>
> "Writing R extensions" section 1.1.3 says
>
>
>
> "The 'Imports' field lists packages whose namespaces are imported from
> (as specified in the NAMESPACE file) but which do not need to be attached.
...
> shortened for brevity ... Packages declared in the 'Depends' field
> should not also be in the 'Imports' field. Version requirements can be
> specified and are checked when the namespace is loaded (since R >= 3.0.0).
"
>
>
>
> It is slightly ambiguous, but seems to mean that the version
> dependencies for both Depends packages and Imports packages are
> checked when the package
> (namespace?) is loaded.
>
>
>
> The release notes for R3.0.0 are more direct. They say
>
>
>
> "loadNamespace() allows a version specification to be given, and this
> is used to check version specifications given in the Imports field
> when a namespace is loaded"
>
>
>
> But some toy (locally built and loaded) examples seem to show that
> while the Depends versions are checked, the Imports version
> constraints are not (on Windows 64, running R3.1.2, see full session_info
later).
>
>
>
> My tests (package2 imports package1) use implicit loading (via the
> package1::fun1() idiom) so I have worked back to try get a minimal
> example of what's causing me problems. I have tried
According to what you have written, that should have failed. So it looks
like a bug.
>
>
>
> loadNamespace('package2', versionCheck = list (op = ">=", version =
> package_version('3.0')))
>
>
>
> This should fail (package2 has version 0.3, not 3.0) but instead it
> seems to load package2, version 0.3 OK.
>
>
>
> Reading the code of loadNamespace, there is some code which says
>
>
>
> if (length(z <- versionCheck) == 3L && !do.call(z$op,
>
> list(as.numeric_version(version), z$version)))
>
> stop(gettextf("namespace %s %s is being loaded, but %s %s is
> required",
>
> sQuote(package), version, z$op, z$version),
>
>domain = NA)
>
>
>
> I think it is the length(z <- versionCheck) == 3L part of the if test
> that is allowing the incorrect version be loaded.
That does seem like a typo.
Duncan Murdoch
>
>
>
> The documentation for loadNamespace says that "versionCheck" is
>
> "NULL or a version specification (a list with components op and
version))."
>
>
>
> If I add a third (nonsense) component to the versionCheck argument
> list, then loadNamespace does what I expect. Is there supposed to be
> a third component in the list, and
Re: [Rd] Problem understanding behaviour of versionCheck for loadNamespace (and when versions for Imports packages are checked)
On 26/11/2014, 7:38 PM, Geoff Lee wrote:
> Many thanks Duncan for the quick response.
A little too quick, it seems...
>
> A bug is a relief in a way. I've been digging my way deeper into this (and
> learning more as I go) for several days now - but it is a diversion from (a
> diversion from) my main goal :-(
>
> Is there somewhere specific I should report or log the bug or will that
> happen from this mailing-list automatically? (I have seen the Bug Tracking
> link on the r-project page and followed that, but don't yet have a Bugzilla
> account, nor know the precise mechanics and protocols for notifying a bug)
If you can put together a simple set of steps to illustrate a bug, then
reporting on bugs.r-project.org is the way to get it recorded.
Reporting it on this list is really hit and miss. But I think from your
previous description, something else is going on. When I try to load a
namespace with a bad version number, I get an error:
loadNamespace("rgl", versionCheck=list(name="rgl", op=">",
version=package_version('3.0')))
Error in loadNamespace("rgl", versionCheck = list(name = "rgl", op =
">", :
namespace ‘rgl’ 0.95.1163 is being loaded, but > 3.0 is required
Duncan Murdoch
>
> Geoff
>
> PS Building package2 - via devtools::build('package2', binary = TRUE) does
> check and insist that I have an appropriate version of the 'to be imported'
> package1 installed in my .libPath().
>
> It was only when I simulated a user who has and older version of the
> Imported package1 (by overwriting the later version of package 1 with an
> earlier version), then trying to load or attach package2 that the (failure
> of the version checking) at loadNamespace time for package1 became apparent
> (well apparentish after quite a bit of digging)
>
> -Original Message-
> From: Duncan Murdoch [mailto:murdoch.dun...@gmail.com]
> Sent: Thursday, 27 November 2014 10:57 AM
> To: Geoff Lee; r-devel@r-project.org
> Subject: Re: [Rd] Problem understanding behaviour of versionCheck for
> loadNamespace (and when versions for Imports packages are checked)
>
> Summary: I think you've found a bug.
>
> On 26/11/2014, 5:39 PM, Geoff Lee wrote:
>> Hi
>>
>>
>>
>> I'm still exploring the R programming universe, so if this is being
>> asked in the wrong place, or in the wrong way (e.g. too verbose or
>> lacking in crucial detail or in the wrong format) please let me know
>>
>>
>>
>> I am trying to understand when the version constraints for packages
>> which appear in the Imports field of a DESCRIPTION file are checked.
>
> I would have assumed they are checked when you try to install the package.
> If you ask for version 3.0, and only have 0.3, the install should fail.
>
> But as you've found, the documents say something else...
>
>>
>>
>>
>> Along the way I've hit a snag understanding what loadNamespace with
>> the versionCheck argument set does. The core of my query is 'am I
>> doing something wrong, or have I stumbled across a bug?'. Probably
>> the former, but after several days I still can't figure it out, so any
>> guidance, hints or outright help would be much appreciated.
>>
>>
>>
>> Thanks in advance
>>
>>
>>
>> Geoff
>>
>>
>>
>> What I've tried so far.
>>
>>
>>
>> "Writing R extensions" section 1.1.3 says
>>
>>
>>
>> "The 'Imports' field lists packages whose namespaces are imported from
>> (as specified in the NAMESPACE file) but which do not need to be attached.
> ...
>> shortened for brevity ... Packages declared in the 'Depends' field
>> should not also be in the 'Imports' field. Version requirements can be
>> specified and are checked when the namespace is loaded (since R >= 3.0.0).
> "
>>
>>
>>
>> It is slightly ambiguous, but seems to mean that the version
>> dependencies for both Depends packages and Imports packages are
>> checked when the package
>> (namespace?) is loaded.
>>
>>
>>
>> The release notes for R3.0.0 are more direct. They say
>>
>>
>>
>> "loadNamespace() allows a version specification to be given, and this
>> is used to check version specifications given in the Imports field
>> when a namespace is loaded"
>>
>>
>>
>> But some toy (locally built and loaded) examples seem to show that
>> while the Depends versions are checked, the Imports version
>> constraints are not (on Windows 64, running R3.1.2, see full session_info
> later).
>>
>>
>>
>> My tests (package2 imports package1) use implicit loading (via the
>> package1::fun1() idiom) so I have worked back to try get a minimal
>> example of what's causing me problems. I have tried
>
> According to what you have written, that should have failed. So it looks
> like a bug.
>>
>>
>>
>> loadNamespace('package2', versionCheck = list (op = ">=", version =
>> package_version('3.0')))
>>
>>
>>
>> This should fail (package2 has version 0.3, not 3.0) but instead it
>> seems to load package2, version 0.3 OK.
>>
>>
>>
>> Reading the code of loadNamespace, there is some code which says
>>
>>
Re: [Rd] Problem understanding behaviour of versionCheck for loadNamespace (and when versions for Imports packages are checked)
On 26/11/2014, 5:39 PM, Geoff Lee wrote:
> Hi
>
>
>
> I'm still exploring the R programming universe, so if this is being asked in
> the wrong place, or in the wrong way (e.g. too verbose or lacking in crucial
> detail or in the wrong format) please let me know
>
>
>
> I am trying to understand when the version constraints for packages which
> appear in the Imports field of a DESCRIPTION file are checked.
>
>
>
> Along the way I've hit a snag understanding what loadNamespace with the
> versionCheck argument set does. The core of my query is 'am I doing
> something wrong, or have I stumbled across a bug?'. Probably the former,
> but after several days I still can't figure it out, so any guidance, hints
> or outright help would be much appreciated.
>
>
>
> Thanks in advance
>
>
>
> Geoff
>
>
>
> What I've tried so far.
>
>
>
> "Writing R extensions" section 1.1.3 says
>
>
>
> "The 'Imports' field lists packages whose namespaces are imported from (as
> specified in the NAMESPACE file) but which do not need to be attached. ...
> shortened for brevity ... Packages declared in the 'Depends' field should
> not also be in the 'Imports' field. Version requirements can be specified
> and are checked when the namespace is loaded (since R >= 3.0.0). "
>
>
>
> It is slightly ambiguous, but seems to mean that the version dependencies
> for both Depends packages and Imports packages are checked when the package
> (namespace?) is loaded.
>
>
>
> The release notes for R3.0.0 are more direct. They say
>
>
>
> "loadNamespace() allows a version specification to be given, and this is
> used to check version specifications given in the Imports field when a
> namespace is loaded"
>
>
>
> But some toy (locally built and loaded) examples seem to show that while the
> Depends versions are checked, the Imports version constraints are not (on
> Windows 64, running R3.1.2, see full session_info later).
>
>
>
> My tests (package2 imports package1) use implicit loading (via the
> package1::fun1() idiom) so I have worked back to try get a minimal example
> of what's causing me problems. I have tried
>
>
>
> loadNamespace('package2', versionCheck = list (op = ">=", version =
> package_version('3.0')))
You need to look at how versionCheck is used in the existing code. It
is used on items that were produced when the package was installed, and
in those, the length of the versionCheck entry really is 3. For
example, the dplyr package imports "lazyeval (>= 0.1.8)". That
specification becomes the list
..$ lazyeval :List of 3
.. ..$ name : chr "lazyeval"
.. ..$ op : chr ">="
.. ..$ version:Classes 'package_version', 'numeric_version' hidden
list of 1
.. .. ..$ : int [1:3] 0 1 8
So if you want to put one of these together, your versionCheck list
should be list(name = "package2", op = ">=", version =
package+version('3.0'))
Duncan Murdoch
>
>
>
> This should fail (package2 has version 0.3, not 3.0) but instead it seems to
> load package2, version 0.3 OK.
>
>
>
> Reading the code of loadNamespace, there is some code which says
>
>
>
> if (length(z <- versionCheck) == 3L && !do.call(z$op,
>
> list(as.numeric_version(version), z$version)))
>
> stop(gettextf("namespace %s %s is being loaded, but %s %s is required",
>
> sQuote(package), version, z$op, z$version),
>
>domain = NA)
>
>
>
> I think it is the length(z <- versionCheck) == 3L part of the if test that
> is allowing the incorrect version be loaded.
>
>
>
> The documentation for loadNamespace says that "versionCheck" is
>
> "NULL or a version specification (a list with components op and version))."
>
>
>
> If I add a third (nonsense) component to the versionCheck argument list,
> then loadNamespace does what I expect. Is there supposed to be a third
> component in the list, and if so what should it be? Or is this a bug?
>
>
>
> I've got this far and am now stumped, hence my query.
>
>
>
> Some output from my tests.
>
>
>
> d> devtools::session_info()
>
> Session
> info
>
> setting value
>
> version R version 3.1.2 (2014-10-31)
>
> system x86_64, mingw32
>
> ui RStudio (0.98.953)
>
> language (EN)
>
> collate English_Australia.1252
>
> tz Australia/Sydney
>
>
>
> Packages
>
>
> package* version date source
>
> devtools 1.6.1 2014-10-07 CRAN (R 3.1.2)
>
> rstudioapi 0.1 2014-03-27 CRAN (R 3.1.1)
>
>
>
> d> # I think this should fail but it does not
>
> d> loadNamespace('package2', versionCheck = list(op='>=', version =
> package_version('3.0')))
>
>
>
>
>
>
>
> d> devtools::session_info()
>
> Session
> info
Re: [Rd] Problem understanding behaviour of versionCheck for loadNamespace (and when versions for Imports packages are checked)
Summary: I think you've found a bug.
On 26/11/2014, 5:39 PM, Geoff Lee wrote:
> Hi
>
>
>
> I'm still exploring the R programming universe, so if this is being asked in
> the wrong place, or in the wrong way (e.g. too verbose or lacking in crucial
> detail or in the wrong format) please let me know
>
>
>
> I am trying to understand when the version constraints for packages which
> appear in the Imports field of a DESCRIPTION file are checked.
I would have assumed they are checked when you try to install the
package. If you ask for version 3.0, and only have 0.3, the install
should fail.
But as you've found, the documents say something else...
>
>
>
> Along the way I've hit a snag understanding what loadNamespace with the
> versionCheck argument set does. The core of my query is 'am I doing
> something wrong, or have I stumbled across a bug?'. Probably the former,
> but after several days I still can't figure it out, so any guidance, hints
> or outright help would be much appreciated.
>
>
>
> Thanks in advance
>
>
>
> Geoff
>
>
>
> What I've tried so far.
>
>
>
> "Writing R extensions" section 1.1.3 says
>
>
>
> "The 'Imports' field lists packages whose namespaces are imported from (as
> specified in the NAMESPACE file) but which do not need to be attached. ...
> shortened for brevity ... Packages declared in the 'Depends' field should
> not also be in the 'Imports' field. Version requirements can be specified
> and are checked when the namespace is loaded (since R >= 3.0.0). "
>
>
>
> It is slightly ambiguous, but seems to mean that the version dependencies
> for both Depends packages and Imports packages are checked when the package
> (namespace?) is loaded.
>
>
>
> The release notes for R3.0.0 are more direct. They say
>
>
>
> "loadNamespace() allows a version specification to be given, and this is
> used to check version specifications given in the Imports field when a
> namespace is loaded"
>
>
>
> But some toy (locally built and loaded) examples seem to show that while the
> Depends versions are checked, the Imports version constraints are not (on
> Windows 64, running R3.1.2, see full session_info later).
>
>
>
> My tests (package2 imports package1) use implicit loading (via the
> package1::fun1() idiom) so I have worked back to try get a minimal example
> of what's causing me problems. I have tried
According to what you have written, that should have failed. So it
looks like a bug.
>
>
>
> loadNamespace('package2', versionCheck = list (op = ">=", version =
> package_version('3.0')))
>
>
>
> This should fail (package2 has version 0.3, not 3.0) but instead it seems to
> load package2, version 0.3 OK.
>
>
>
> Reading the code of loadNamespace, there is some code which says
>
>
>
> if (length(z <- versionCheck) == 3L && !do.call(z$op,
>
> list(as.numeric_version(version), z$version)))
>
> stop(gettextf("namespace %s %s is being loaded, but %s %s is required",
>
> sQuote(package), version, z$op, z$version),
>
>domain = NA)
>
>
>
> I think it is the length(z <- versionCheck) == 3L part of the if test that
> is allowing the incorrect version be loaded.
That does seem like a typo.
Duncan Murdoch
>
>
>
> The documentation for loadNamespace says that "versionCheck" is
>
> "NULL or a version specification (a list with components op and version))."
>
>
>
> If I add a third (nonsense) component to the versionCheck argument list,
> then loadNamespace does what I expect. Is there supposed to be a third
> component in the list, and if so what should it be? Or is this a bug?
>
>
>
> I've got this far and am now stumped, hence my query.
>
>
>
> Some output from my tests.
>
>
>
> d> devtools::session_info()
>
> Session
> info
>
> setting value
>
> version R version 3.1.2 (2014-10-31)
>
> system x86_64, mingw32
>
> ui RStudio (0.98.953)
>
> language (EN)
>
> collate English_Australia.1252
>
> tz Australia/Sydney
>
>
>
> Packages
>
>
> package* version date source
>
> devtools 1.6.1 2014-10-07 CRAN (R 3.1.2)
>
> rstudioapi 0.1 2014-03-27 CRAN (R 3.1.1)
>
>
>
> d> # I think this should fail but it does not
>
> d> loadNamespace('package2', versionCheck = list(op='>=', version =
> package_version('3.0')))
>
>
>
>
>
>
>
> d> devtools::session_info()
>
> Session
> info
>
> setting value
>
> version R version 3.1.2 (2014-10-31)
>
> system x86_64, mingw32
>
> ui RStudio (0.98.953)
>
> language (EN)
>
> collate English_Australia.1
[Rd] Problem understanding behaviour of versionCheck for loadNamespace (and when versions for Imports packages are checked)
Hi
I'm still exploring the R programming universe, so if this is being asked in
the wrong place, or in the wrong way (e.g. too verbose or lacking in crucial
detail or in the wrong format) please let me know
I am trying to understand when the version constraints for packages which
appear in the Imports field of a DESCRIPTION file are checked.
Along the way I've hit a snag understanding what loadNamespace with the
versionCheck argument set does. The core of my query is 'am I doing
something wrong, or have I stumbled across a bug?'. Probably the former,
but after several days I still can't figure it out, so any guidance, hints
or outright help would be much appreciated.
Thanks in advance
Geoff
What I've tried so far.
"Writing R extensions" section 1.1.3 says
"The 'Imports' field lists packages whose namespaces are imported from (as
specified in the NAMESPACE file) but which do not need to be attached. ...
shortened for brevity ... Packages declared in the 'Depends' field should
not also be in the 'Imports' field. Version requirements can be specified
and are checked when the namespace is loaded (since R >= 3.0.0). "
It is slightly ambiguous, but seems to mean that the version dependencies
for both Depends packages and Imports packages are checked when the package
(namespace?) is loaded.
The release notes for R3.0.0 are more direct. They say
"loadNamespace() allows a version specification to be given, and this is
used to check version specifications given in the Imports field when a
namespace is loaded"
But some toy (locally built and loaded) examples seem to show that while the
Depends versions are checked, the Imports version constraints are not (on
Windows 64, running R3.1.2, see full session_info later).
My tests (package2 imports package1) use implicit loading (via the
package1::fun1() idiom) so I have worked back to try get a minimal example
of what's causing me problems. I have tried
loadNamespace('package2', versionCheck = list (op = ">=", version =
package_version('3.0')))
This should fail (package2 has version 0.3, not 3.0) but instead it seems to
load package2, version 0.3 OK.
Reading the code of loadNamespace, there is some code which says
if (length(z <- versionCheck) == 3L && !do.call(z$op,
list(as.numeric_version(version), z$version)))
stop(gettextf("namespace %s %s is being loaded, but %s %s is required",
sQuote(package), version, z$op, z$version),
domain = NA)
I think it is the length(z <- versionCheck) == 3L part of the if test that
is allowing the incorrect version be loaded.
The documentation for loadNamespace says that "versionCheck" is
"NULL or a version specification (a list with components op and version))."
If I add a third (nonsense) component to the versionCheck argument list,
then loadNamespace does what I expect. Is there supposed to be a third
component in the list, and if so what should it be? Or is this a bug?
I've got this far and am now stumped, hence my query.
Some output from my tests.
d> devtools::session_info()
Session
info
setting value
version R version 3.1.2 (2014-10-31)
system x86_64, mingw32
ui RStudio (0.98.953)
language (EN)
collate English_Australia.1252
tz Australia/Sydney
Packages
package* version date source
devtools 1.6.1 2014-10-07 CRAN (R 3.1.2)
rstudioapi 0.1 2014-03-27 CRAN (R 3.1.1)
d> # I think this should fail but it does not
d> loadNamespace('package2', versionCheck = list(op='>=', version =
package_version('3.0')))
d> devtools::session_info()
Session
info
setting value
version R version 3.1.2 (2014-10-31)
system x86_64, mingw32
ui RStudio (0.98.953)
language (EN)
collate English_Australia.1252
tz Australia/Sydney
Packages
package* version date source
devtools 1.6.1 2014-10-07 CRAN (R 3.1.2)
package2 0.3 2014-11-24 local
rstudioapi 0.1 2014-03-27 CRAN (R 3.1.1)
d> #Try again with a third (nonsense) entry in the versionCheck list
d> unloadNamespace('package2')
d> loadNamespace('package2', versionCheck = list(op='>=', version =
package_version('3.0'), please = 'check it'))
Error in loadNamespace("package2", versionCheck = list(op = ">=", version =
package_version("3.0"), :
namespace 'package2' 0.3 is being loaded, but >= 3.0 is required
d> devtools::session_info()
Session
info--
Re: [Rd] testing dontrun examples
On 26/11/2014, 1:45 PM, Paul Gilbert wrote: > Is there a good strategy for testing examples which should not be run by > default? For instance, I have examples which get data from the Internet. > If I wrap them in try() then they can be skipped if the Internet is not > available, but may not be tested in cases when I would like to know > about the failure. (Not to mention that the example syntax is ugly.) > > If I mark them \dontrun or \donttest then they are not tested. I could > mark them \dontrun and then use example() but for this, in addition to > run.dontrun=TRUE, I would need to specify all topics for a package, and > I don't see how to do this, missing topic does not work. > > Wishlist: what I would really like is R CMD check --run-dontrun pkg We have that in R-devel, so everyone will have it next April, but there will possibly be bugs unless people like you try it out now. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] testing dontrun examples
On Wed, Nov 26, 2014 at 12:45 PM, Paul Gilbert wrote: > Is there a good strategy for testing examples which should not be run by > default? For instance, I have examples which get data from the Internet. If > I wrap them in try() then they can be skipped if the Internet is not > available, but may not be tested in cases when I would like to know about > the failure. (Not to mention that the example syntax is ugly.) > > If I mark them \dontrun or \donttest then they are not tested. I could > mark them \dontrun and then use example() but for this, in addition to > run.dontrun=TRUE, I would need to specify all topics for a package, and I > don't see how to do this, missing topic does not work. > > Wishlist: what I would really like is R CMD check --run-dontrun pkg > I agree that would be nice to have. My solution was just to have a private function (pkg:::run_examples()) that runs all the examples. It has to be manually updated when adding a new example however. The devtools solution has not always worked for me when there are external dependencies (like internet download, etc.) THK > > Suggestions? > > Thanks, > Paul > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- http://www.keittlab.org/ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] testing dontrun examples
You can try devtools::run_examples(test = TRUE) (assuming your working directory is the top-level package directory) Hadley On Wed, Nov 26, 2014 at 12:45 PM, Paul Gilbert wrote: > Is there a good strategy for testing examples which should not be run by > default? For instance, I have examples which get data from the Internet. If > I wrap them in try() then they can be skipped if the Internet is not > available, but may not be tested in cases when I would like to know about > the failure. (Not to mention that the example syntax is ugly.) > > If I mark them \dontrun or \donttest then they are not tested. I could mark > them \dontrun and then use example() but for this, in addition to > run.dontrun=TRUE, I would need to specify all topics for a package, and I > don't see how to do this, missing topic does not work. > > Wishlist: what I would really like is R CMD check --run-dontrun pkg > > Suggestions? > > Thanks, > Paul > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] testing dontrun examples
On 14-11-26 02:09 PM, Spencer Graves wrote: Hi, Paul: "if(!fda::CRAN())" runs code except with "R CMD check –as-cran". I use it so CRAN checks skip examples that (a) need the Internet or (b) take too long for CRAN. Spencer fda::CRAN() gives TRUE on my home machine, I think because I use several variables like _R_CHECK_HAVE_MYSQL_=TRUE to control whether some tests get run. (Not all CRAN test servers have all resources.) But, more importantly, wouldn't this strategy prevent CRAN from automatically running more extensive testing of the examples if they decided to do that sometimes? Paul Hope this helps. Spencer On 11/26/2014 10:45 AM, Paul Gilbert wrote: Is there a good strategy for testing examples which should not be run by default? For instance, I have examples which get data from the Internet. If I wrap them in try() then they can be skipped if the Internet is not available, but may not be tested in cases when I would like to know about the failure. (Not to mention that the example syntax is ugly.) If I mark them \dontrun or \donttest then they are not tested. I could mark them \dontrun and then use example() but for this, in addition to run.dontrun=TRUE, I would need to specify all topics for a package, and I don't see how to do this, missing topic does not work. Wishlist: what I would really like is R CMD check --run-dontrun pkg Suggestions? Thanks, Paul __ 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
Re: [Rd] testing dontrun examples
Hi, Paul: "if(!fda::CRAN())" runs code except with "R CMD check –as-cran". I use it so CRAN checks skip examples that (a) need the Internet or (b) take too long for CRAN. Hope this helps. Spencer On 11/26/2014 10:45 AM, Paul Gilbert wrote: Is there a good strategy for testing examples which should not be run by default? For instance, I have examples which get data from the Internet. If I wrap them in try() then they can be skipped if the Internet is not available, but may not be tested in cases when I would like to know about the failure. (Not to mention that the example syntax is ugly.) If I mark them \dontrun or \donttest then they are not tested. I could mark them \dontrun and then use example() but for this, in addition to run.dontrun=TRUE, I would need to specify all topics for a package, and I don't see how to do this, missing topic does not work. Wishlist: what I would really like is R CMD check --run-dontrun pkg Suggestions? Thanks, Paul __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Spencer Graves, PE, PhD President and Chief Technology Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 web: www.structuremonitoring.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] testing dontrun examples
Is there a good strategy for testing examples which should not be run by default? For instance, I have examples which get data from the Internet. If I wrap them in try() then they can be skipped if the Internet is not available, but may not be tested in cases when I would like to know about the failure. (Not to mention that the example syntax is ugly.) If I mark them \dontrun or \donttest then they are not tested. I could mark them \dontrun and then use example() but for this, in addition to run.dontrun=TRUE, I would need to specify all topics for a package, and I don't see how to do this, missing topic does not work. Wishlist: what I would really like is R CMD check --run-dontrun pkg Suggestions? Thanks, Paul __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
