Re: [Rd] oddity in transform

[Emil Bode]

I think you meant to call BOD[,1]
From ?transform, the ... arguments are supposed to be vectors, and BOD[1] is 
still a data.frame (with one column). So I don't think it's surprising 
transform gets confused by which name to use (X, or Time?), and kind of 
compromises on the name "Time". It's also in a note in ?transform: "If some of 
the values are not vectors of the appropriate length, you deserve whatever you 
get!"
And if you want to do it with multiple extra columns (and are not satisfied 
with these labels), I think the proper way to go would be " transform(BOD, 
X=BOD[,1]*seq(6), Y=BOD[,2]*seq(6))"
 
If you want to trace it back further, it's not in transform but in data.frame. 
Column-names are prepended with a higher-level name if the object has more than 
one column.
And it uses the tag-name if simply supplied with a vector:
data.frame(BOD[1:2], X=BOD[1]*seq(6)) takes the name of the only column of 
BOD[1], Time. Only because that column name is already present, it's changed to 
Time.1
data.frame(BOD[1:2], X=BOD[,1]*seq(6)) gives third column-name X (as X is now a 
vector)
data.frame(BOD[1:2], X=BOD[1:2]*seq(6)) or with BOD[,1:2] gives columns names 
X.Time and X.demand, to show these (multiple) columns are coming from X

So I don't think there's much to fix here. I this case having X.Time in all 
cases would have been better, but in general the column-naming of data.frame 
works, changing it would likely cause a lot of problems.
You can always change the column-names later.

Best regards, 
Emil Bode
 
Data-analyst
 
+31 6 43 83 89 33
emil.b...@dans.knaw.nl
 
DANS: Netherlands Institute for Permanent Access to Digital Research Resources
Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | 
i...@dans.knaw.nl  | dans.knaw.nl 

DANS is an institute of the Dutch Academy KNAW  and funding 
organisation NWO . 

On 23/07/2018, 16:52, "R-devel on behalf of Gabor Grothendieck" 
 wrote:

Note the inconsistency in the names in these two examples.  X.Time in
the first case and Time.1 in the second case.

  > transform(BOD, X = BOD[1:2] * seq(6))
Time demand X.Time X.demand
  118.3  1  8.3
  22   10.3  4 20.6
  33   19.0  9 57.0
  44   16.0 16 64.0
  55   15.6 25 78.0
  67   19.8 42118.8

  > transform(BOD, X = BOD[1] * seq(6))
Time demand Time.1
  118.3  1
  22   10.3  4
  33   19.0  9
  44   16.0 16
  55   15.6 25
  67   19.8 42

-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

__
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] Library lib.loc Option Ignored for Dependencies

[Martin Maechler]

> Benjamin Tyner 
> on Sat, 21 Jul 2018 13:42:43 -0400 writes:

> Not sure whether it is the same issue as was raised here:
> https://stat.ethz.ch/pipermail/r-devel/2010-October/058729.html

> but in any case perhaps the problem could partially be remedied on line 
> 245 of src/library/base/R/library.R by passing the lib.loc to 
> .getRequiredPackages2() ...here is a patch (untested)

> Index: src/library/base/R/library.R
> ===
> --- src/library/base/R/library.R    (revision 74997)
> +++ src/library/base/R/library.R    (working copy)
> @@ -242,7 +242,7 @@
>  pos <- 2
>  } else pos <- npos
>  }
> -    .getRequiredPackages2(pkgInfo, quietly = quietly)
> +    .getRequiredPackages2(pkgInfo, lib.loc = lib.loc, quietly = 
quietly)
>  deps <- unique(names(pkgInfo$Depends))

>  ## If the namespace mechanism is available and the package

This - directly - fails even more miserably e.g. in my own setup
when I have dependency to my package.

But it seems a good idea to use 'lib.loc', and safer and
probably better than the current code maybe to use

  .getRequiredPackages2(pkgInfo,
lib.loc = c(lib.loc, .libPaths()),
quietly = quietly)

instead of the current code which uses lib.loc = NULL
equivalently to   lib.loc = .libPaths()

Others / ideas?
Reproducible examples with small fake packages?

Martin

> On 07/21/2018 12:34 PM, Martin Maechler wrote:
>>> Benjamin Tyner
>>> on Fri, 20 Jul 2018 19:42:09 -0400 writes:
>> > Here's a trick/workaround; if lib.loc is the path to your
>> > library, then prior to calling library(),
>> 
>> >> environment(.libPaths)$.lib.loc <- lib.loc
>> 
>> Well, that is quite a "trick"  -- and potentially a pretty
>> dangerous one, not intended when making .libPaths a closure 
>> 
>> 
>> I do think that there is a problem with R's dealing of R_LIBS
>> and other libPaths settings, notably when checking packages and
>> within that recompiling vignettes etc, where the R process
>> starts new versions of R via system() / system2() and then gets
>> to wrong .libPaths() settings,
>> and I personally would be very happy if we got reprex'es with
>> small fake packages -- possibly only easily reproducible on
>> unix-alikes ... so we could address this as a bug (or more than
>> one) to be fixed.
>> 
>> Notably with the 3.4.x --> 3.5.0 transition and my/our tendency
>> of having quite a few paths in R_LIBS / lib.loc / ... I've been
>> bitten by problems when the wrong version of package was taken
>> from the wrong library path 
>> 
>> Martin
>> 
>> 
>> >> 

>> >> Good day,
>> >>
>> >> If there's a library folder of the latest R packages and
>> >> a particular package from it is loaded using the lib.loc
>> >> option, the dependencies of that package are still
>> >> attempted to be loaded from another folder of older
>> >> packages specified by R_LIBS, which may cause errors
>> >> about version requirements not being met. The
>> >> documentation of the library function doesn't explain
>> >> what the intended result is in such a case, but it could
>> >> reasonably be expected that R would also load the
>> >> dependencies from the user-specified lib.loc folder.
>> >>
>> >> --
>> >> Dario Strbenac University of Sydney Camperdown NSW 2050
>> >> Australia

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] oddity in transform

[Gabor Grothendieck]

The idea is that one wants to write the line of code below
 in a general way which works the same
whether you specify ix as one column or multiple columns but the naming entirely
changes when you do this and BOD[, 1] and transform(BOD, X=..., Y=...) or
other hard coding solutions still require writing multiple cases.

ix <- 1:2
transform(BOD, X = BOD[ix] * seq(6))



On Tue, Jul 24, 2018 at 7:14 AM, Emil Bode  wrote:
> I think you meant to call BOD[,1]
> From ?transform, the ... arguments are supposed to be vectors, and BOD[1] is 
> still a data.frame (with one column). So I don't think it's surprising 
> transform gets confused by which name to use (X, or Time?), and kind of 
> compromises on the name "Time". It's also in a note in ?transform: "If some 
> of the values are not vectors of the appropriate length, you deserve whatever 
> you get!"
> And if you want to do it with multiple extra columns (and are not satisfied 
> with these labels), I think the proper way to go would be " transform(BOD, 
> X=BOD[,1]*seq(6), Y=BOD[,2]*seq(6))"
>
> If you want to trace it back further, it's not in transform but in 
> data.frame. Column-names are prepended with a higher-level name if the object 
> has more than one column.
> And it uses the tag-name if simply supplied with a vector:
> data.frame(BOD[1:2], X=BOD[1]*seq(6)) takes the name of the only column of 
> BOD[1], Time. Only because that column name is already present, it's changed 
> to Time.1
> data.frame(BOD[1:2], X=BOD[,1]*seq(6)) gives third column-name X (as X is now 
> a vector)
> data.frame(BOD[1:2], X=BOD[1:2]*seq(6)) or with BOD[,1:2] gives columns names 
> X.Time and X.demand, to show these (multiple) columns are coming from X
>
> So I don't think there's much to fix here. I this case having X.Time in all 
> cases would have been better, but in general the column-naming of data.frame 
> works, changing it would likely cause a lot of problems.
> You can always change the column-names later.
>
> Best regards,
> Emil Bode
>
> Data-analyst
>
> +31 6 43 83 89 33
> emil.b...@dans.knaw.nl
>
> DANS: Netherlands Institute for Permanent Access to Digital Research Resources
> Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | 
> i...@dans.knaw.nl  | dans.knaw.nl 
> 
> DANS is an institute of the Dutch Academy KNAW  and 
> funding organisation NWO .
>
> On 23/07/2018, 16:52, "R-devel on behalf of Gabor Grothendieck" 
>  wrote:
>
> Note the inconsistency in the names in these two examples.  X.Time in
> the first case and Time.1 in the second case.
>
>   > transform(BOD, X = BOD[1:2] * seq(6))
> Time demand X.Time X.demand
>   118.3  1  8.3
>   22   10.3  4 20.6
>   33   19.0  9 57.0
>   44   16.0 16 64.0
>   55   15.6 25 78.0
>   67   19.8 42118.8
>
>   > transform(BOD, X = BOD[1] * seq(6))
> Time demand Time.1
>   118.3  1
>   22   10.3  4
>   33   19.0  9
>   44   16.0 16
>   55   15.6 25
>   67   19.8 42
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>



-- 
Statistics & Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] oddity in transform

[Ista Zahn]

I don't think it has much to do with transform in particular:

> BOD <- data.frame(Time = 1:6, demand = runif(6))
> BOD[["X"]] <- BOD[1:2] * seq(6); BOD
  Timedemand X.Time  X.demand
11 0.8649628  1 0.8649628
22 0.5895380  4 1.1790761
33 0.6854635  9 2.0563906
44 0.4255801 16 1.7023206
55 0.5738793 25 2.8693967
66 0.9996713 36 5.9980281
> BOD <- data.frame(Time = 1:6, demand = runif(6))
> BOD[["X"]] <- BOD[1] * seq(6); BOD
  Time demand Time
11 0.729902311
22 0.617214224
33 0.023891609
44 0.28341746   16
55 0.06116124   25
66 0.67966577   36

--Ista


On Tue, Jul 24, 2018 at 7:59 AM, Gabor Grothendieck
 wrote:
> The idea is that one wants to write the line of code below
>  in a general way which works the same
> whether you specify ix as one column or multiple columns but the naming 
> entirely
> changes when you do this and BOD[, 1] and transform(BOD, X=..., Y=...) or
> other hard coding solutions still require writing multiple cases.
>
> ix <- 1:2
> transform(BOD, X = BOD[ix] * seq(6))
>
>
>
> On Tue, Jul 24, 2018 at 7:14 AM, Emil Bode  wrote:
>> I think you meant to call BOD[,1]
>> From ?transform, the ... arguments are supposed to be vectors, and BOD[1] is 
>> still a data.frame (with one column). So I don't think it's surprising 
>> transform gets confused by which name to use (X, or Time?), and kind of 
>> compromises on the name "Time". It's also in a note in ?transform: "If some 
>> of the values are not vectors of the appropriate length, you deserve 
>> whatever you get!"
>> And if you want to do it with multiple extra columns (and are not satisfied 
>> with these labels), I think the proper way to go would be " transform(BOD, 
>> X=BOD[,1]*seq(6), Y=BOD[,2]*seq(6))"
>>
>> If you want to trace it back further, it's not in transform but in 
>> data.frame. Column-names are prepended with a higher-level name if the 
>> object has more than one column.
>> And it uses the tag-name if simply supplied with a vector:
>> data.frame(BOD[1:2], X=BOD[1]*seq(6)) takes the name of the only column of 
>> BOD[1], Time. Only because that column name is already present, it's changed 
>> to Time.1
>> data.frame(BOD[1:2], X=BOD[,1]*seq(6)) gives third column-name X (as X is 
>> now a vector)
>> data.frame(BOD[1:2], X=BOD[1:2]*seq(6)) or with BOD[,1:2] gives columns 
>> names X.Time and X.demand, to show these (multiple) columns are coming from X
>>
>> So I don't think there's much to fix here. I this case having X.Time in all 
>> cases would have been better, but in general the column-naming of data.frame 
>> works, changing it would likely cause a lot of problems.
>> You can always change the column-names later.
>>
>> Best regards,
>> Emil Bode
>>
>> Data-analyst
>>
>> +31 6 43 83 89 33
>> emil.b...@dans.knaw.nl
>>
>> DANS: Netherlands Institute for Permanent Access to Digital Research 
>> Resources
>> Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | 
>> i...@dans.knaw.nl  | dans.knaw.nl 
>> 
>> DANS is an institute of the Dutch Academy KNAW  and 
>> funding organisation NWO .
>>
>> On 23/07/2018, 16:52, "R-devel on behalf of Gabor Grothendieck" 
>>  wrote:
>>
>> Note the inconsistency in the names in these two examples.  X.Time in
>> the first case and Time.1 in the second case.
>>
>>   > transform(BOD, X = BOD[1:2] * seq(6))
>> Time demand X.Time X.demand
>>   118.3  1  8.3
>>   22   10.3  4 20.6
>>   33   19.0  9 57.0
>>   44   16.0 16 64.0
>>   55   15.6 25 78.0
>>   67   19.8 42118.8
>>
>>   > transform(BOD, X = BOD[1] * seq(6))
>> Time demand Time.1
>>   118.3  1
>>   22   10.3  4
>>   33   19.0  9
>>   44   16.0 16
>>   55   15.6 25
>>   67   19.8 42
>>
>> --
>> Statistics & Software Consulting
>> GKX Group, GKX Associates Inc.
>> tel: 1-877-GKX-GROUP
>> email: ggrothendieck at gmail.com
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
>
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
>
> __
> 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] oddity in transform

[Ista Zahn]

On Tue, Jul 24, 2018 at 11:41 AM, Ista Zahn  wrote:
> I don't think it has much to do with transform in particular:
>
>> BOD <- data.frame(Time = 1:6, demand = runif(6))
>> BOD[["X"]] <- BOD[1:2] * seq(6); BOD
>   Timedemand X.Time  X.demand
> 11 0.8649628  1 0.8649628
> 22 0.5895380  4 1.1790761
> 33 0.6854635  9 2.0563906
> 44 0.4255801 16 1.7023206
> 55 0.5738793 25 2.8693967
> 66 0.9996713 36 5.9980281
>> BOD <- data.frame(Time = 1:6, demand = runif(6))
>> BOD[["X"]] <- BOD[1] * seq(6); BOD
>   Time demand Time
> 11 0.729902311
> 22 0.617214224
> 33 0.023891609
> 44 0.28341746   16
> 55 0.06116124   25
> 66 0.67966577   36

Ugh, well, I see now that

BOD[["X"]] <- BOD[1:2] * seq(6); BOD

and

transform(BOD, X = BOD[1:2] * seq(6))

don't produce the same thing, despite printing in ways that look
similar. However,

data.frame(BOD, X = BOD[1:2] * seq(6))

and

data.frame(BOD, X = BOD[1] * seq(6))

do produce the same result as transform, so the point about this being
much more pervasive still holds.

--Ista



>
> --Ista
>
>
> On Tue, Jul 24, 2018 at 7:59 AM, Gabor Grothendieck
>  wrote:
>> The idea is that one wants to write the line of code below
>>  in a general way which works the same
>> whether you specify ix as one column or multiple columns but the naming 
>> entirely
>> changes when you do this and BOD[, 1] and transform(BOD, X=..., Y=...) or
>> other hard coding solutions still require writing multiple cases.
>>
>> ix <- 1:2
>> transform(BOD, X = BOD[ix] * seq(6))
>>
>>
>>
>> On Tue, Jul 24, 2018 at 7:14 AM, Emil Bode  wrote:
>>> I think you meant to call BOD[,1]
>>> From ?transform, the ... arguments are supposed to be vectors, and BOD[1] 
>>> is still a data.frame (with one column). So I don't think it's surprising 
>>> transform gets confused by which name to use (X, or Time?), and kind of 
>>> compromises on the name "Time". It's also in a note in ?transform: "If some 
>>> of the values are not vectors of the appropriate length, you deserve 
>>> whatever you get!"
>>> And if you want to do it with multiple extra columns (and are not satisfied 
>>> with these labels), I think the proper way to go would be " transform(BOD, 
>>> X=BOD[,1]*seq(6), Y=BOD[,2]*seq(6))"
>>>
>>> If you want to trace it back further, it's not in transform but in 
>>> data.frame. Column-names are prepended with a higher-level name if the 
>>> object has more than one column.
>>> And it uses the tag-name if simply supplied with a vector:
>>> data.frame(BOD[1:2], X=BOD[1]*seq(6)) takes the name of the only column of 
>>> BOD[1], Time. Only because that column name is already present, it's 
>>> changed to Time.1
>>> data.frame(BOD[1:2], X=BOD[,1]*seq(6)) gives third column-name X (as X is 
>>> now a vector)
>>> data.frame(BOD[1:2], X=BOD[1:2]*seq(6)) or with BOD[,1:2] gives columns 
>>> names X.Time and X.demand, to show these (multiple) columns are coming from 
>>> X
>>>
>>> So I don't think there's much to fix here. I this case having X.Time in all 
>>> cases would have been better, but in general the column-naming of 
>>> data.frame works, changing it would likely cause a lot of problems.
>>> You can always change the column-names later.
>>>
>>> Best regards,
>>> Emil Bode
>>>
>>> Data-analyst
>>>
>>> +31 6 43 83 89 33
>>> emil.b...@dans.knaw.nl
>>>
>>> DANS: Netherlands Institute for Permanent Access to Digital Research 
>>> Resources
>>> Anna van Saksenlaan 51 | 2593 HW Den Haag | +31 70 349 44 50 | 
>>> i...@dans.knaw.nl  | dans.knaw.nl 
>>> 
>>> DANS is an institute of the Dutch Academy KNAW  and 
>>> funding organisation NWO .
>>>
>>> On 23/07/2018, 16:52, "R-devel on behalf of Gabor Grothendieck" 
>>>  wrote:
>>>
>>> Note the inconsistency in the names in these two examples.  X.Time in
>>> the first case and Time.1 in the second case.
>>>
>>>   > transform(BOD, X = BOD[1:2] * seq(6))
>>> Time demand X.Time X.demand
>>>   118.3  1  8.3
>>>   22   10.3  4 20.6
>>>   33   19.0  9 57.0
>>>   44   16.0 16 64.0
>>>   55   15.6 25 78.0
>>>   67   19.8 42118.8
>>>
>>>   > transform(BOD, X = BOD[1] * seq(6))
>>> Time demand Time.1
>>>   118.3  1
>>>   22   10.3  4
>>>   33   19.0  9
>>>   44   16.0 16
>>>   55   15.6 25
>>>   67   19.8 42
>>>
>>> --
>>> Statistics & Software Consulting
>>> GKX Group, GKX Associates Inc.
>>> tel: 1-877-GKX-GROUP
>>> email: ggrothendieck at gmail.com
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>>
>>
>> --
>> Statistics & Software Consulting
>> GKX Group, GKX Associates Inc.
>> tel: 1-877-GKX-GROU

Re: [Rd] Library lib.loc Option Ignored for Dependencies

[Benjamin Tyner]

On 07/24/2018 07:50 AM, Martin Maechler wrote:

Benjamin Tyner
 on Sat, 21 Jul 2018 13:42:43 -0400 writes:

 > Not sure whether it is the same issue as was raised here:
 > https://stat.ethz.ch/pipermail/r-devel/2010-October/058729.html

 > but in any case perhaps the problem could partially be remedied on line
 > 245 of src/library/base/R/library.R by passing the lib.loc to
 > .getRequiredPackages2() ...here is a patch (untested)

 > Index: src/library/base/R/library.R
 > ===
 > --- src/library/base/R/library.R    (revision 74997)
 > +++ src/library/base/R/library.R    (working copy)
 > @@ -242,7 +242,7 @@
 >  pos <- 2
 >  } else pos <- npos
 >  }
 > -    .getRequiredPackages2(pkgInfo, quietly = quietly)
 > +    .getRequiredPackages2(pkgInfo, lib.loc = lib.loc, quietly = 
quietly)
 >  deps <- unique(names(pkgInfo$Depends))

 >  ## If the namespace mechanism is available and the package

This - directly - fails even more miserably e.g. in my own setup
when I have dependency to my package.

But it seems a good idea to use 'lib.loc', and safer and
probably better than the current code maybe to use

   .getRequiredPackages2(pkgInfo,
lib.loc = c(lib.loc, .libPaths()),
quietly = quietly)

instead of the current code which uses lib.loc = NULL
equivalently to   lib.loc = .libPaths()

Seems reasonable to me.


Others / ideas?
Reproducible examples with small fake packages?

Or how about an example with a "real" CRAN package with just one dependency:

    > dir.create("~/lib")
    > list.files("~/lib")
    character(0)
    > install.packages("spam", lib = "~/lib", dependencies = TRUE)
    > list.files("~/lib")
    [1] "dotCall64" "spam"
    > library(spam, lib.loc = "~/lib")
    Error: package ‘dotCall64’ required by ‘spam’ could not be found



Martin

 > On 07/21/2018 12:34 PM, Martin Maechler wrote:
 >>> Benjamin Tyner
 >>> on Fri, 20 Jul 2018 19:42:09 -0400 writes:
 >> > Here's a trick/workaround; if lib.loc is the path to your
 >> > library, then prior to calling library(),
 >>
 >> >> environment(.libPaths)$.lib.loc <- lib.loc
 >>
 >> Well, that is quite a "trick"  -- and potentially a pretty
 >> dangerous one, not intended when making .libPaths a closure 
 >>
 >>
 >> I do think that there is a problem with R's dealing of R_LIBS
 >> and other libPaths settings, notably when checking packages and
 >> within that recompiling vignettes etc, where the R process
 >> starts new versions of R via system() / system2() and then gets
 >> to wrong .libPaths() settings,
 >> and I personally would be very happy if we got reprex'es with
 >> small fake packages -- possibly only easily reproducible on
 >> unix-alikes ... so we could address this as a bug (or more than
 >> one) to be fixed.
 >>
 >> Notably with the 3.4.x --> 3.5.0 transition and my/our tendency
 >> of having quite a few paths in R_LIBS / lib.loc / ... I've been
 >> bitten by problems when the wrong version of package was taken
 >> from the wrong library path 
 >>
 >> Martin
 >>
 >>
 >> >> 

 >> >> Good day,
 >> >>
 >> >> If there's a library folder of the latest R packages and
 >> >> a particular package from it is loaded using the lib.loc
 >> >> option, the dependencies of that package are still
 >> >> attempted to be loaded from another folder of older
 >> >> packages specified by R_LIBS, which may cause errors
 >> >> about version requirements not being met. The
 >> >> documentation of the library function doesn't explain
 >> >> what the intended result is in such a case, but it could
 >> >> reasonably be expected that R would also load the
 >> >> dependencies from the user-specified lib.loc folder.
 >> >>
 >> >> --
 >> >> Dario Strbenac University of Sydney Camperdown NSW 2050
 >> >> Australia


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Library lib.loc Option Ignored for Dependencies

[Dario Strbenac]

Good day,

A self-contained example which reproduces the problem is

packagesFolder <- tempdir()
latestFolder <- file.path(packagesFolder, "latest")
dir.create(latestFolder)

devtools::create(file.path(latestFolder, "statistics"), description = 
list(Version = "1.1.0", Depends = "extras (>= 1.0.5)"))
devtools::create(file.path(packagesFolder, "extras"), description = 
list(Version = "1.0.0"))
devtools::create(file.path(latestFolder, "extras"), description = list(Version 
= "1.1.0"))

latestInstall <- file.path(.libPaths()[1], "latest")
dir.create(latestInstall)
install.packages(file.path(packagesFolder, "extras"), type = "source", repos = 
NULL)
install.packages(file.path(latestFolder, "extras"), type = "source", repos = 
NULL, lib = latestInstall)
install.packages(file.path(latestFolder, "statistics"), type = "source", repos 
= NULL, lib = latestInstall)

> library(statistics, lib.loc = latestInstall)
  Error: package ‘extras’ 1.0.0 was found, but >= 1.0.5 is required by 
‘statistics’

The latest version of the statistics package is loaded, but the directory of 
latest packages is ignored by R when it considers the package dependency.

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel