[datatable-help] Error in a package that imports data.table

[Victor Kryukov]

OK, I think I have solved it. The problem seemed to be related to FAQ 2.23.

When I was *importing* data.table with 'Imports:', I think what was going
on is that R was making functions from data.table's namespace available to
my package, but the data.table package itself was not loaded. As a
consequence, .onLoad was never called and hense FAQ 2.23's magic never
happened.

Now my depends section in DESCRIPTION looks like this:

Depends:
    data.table,
    lubridate

and everything seems to work - no error messages about .rbind.data.table
not available, and lubridate's hour, minute etc. mask data.table's, which
is what expected. The order does matter in that case.

Thanks for Matthew and Steve for providing support. At least I had a reason
to downloaded data.table  and poke around its sources; wish it was
available on github...

Regards,
Victor

On Thu, Mar 7, 2013 at 12:55 AM, Matthew Dowle <mdowle at mdowle.plus.com>wrote:

>
> Victor,
>
> As Steve says you shouldn't need to do that.
>
> If it's just the mask warnings you're trying to suppress have you tried :
>
>     suppressPackageStartupMessages**({
>         library(...)
>         library(...)
>     })
>
> I haven't used lubdridate before. I tried :
>
>  install.packages("lubdridate")
>>
> Warning message:
> package ‘lubdridate’ is not available (for R version 2.15.3)
>
>>
>>
> Seems odd.   Anyway: is lubridate fast?   As the code comment you pasted
> said, it stores Date as numeric (type double) doesn't it, as base R does?
> Won't that mean sorting won't be as fast on it?  That's the reason IDate
> exists and what the I stands for.
>
> Matthew
>
>
>
> On 07.03.2013 05:40, Steve Lianoglou wrote:
>
>> Hi,
>>
>> On Thu, Mar 7, 2013 at 12:22 AM, Victor Kryukov
>> <victor.kryukov at gmail.com> wrote:
>>
>>> Update: it looks the order in NAMESPACE doesn't matter for that
>>> particular
>>> problem. I can confirm that when I change it the order of package loading
>>> changes, as it's either data.table or lubridate that warns about
>>> overwritting each other's functions, but the problem exists in either
>>> case.
>>>
>>> I think my next steps will be to perform a surgery on data.table by
>>> removing
>>> all IDateTime from my local copy - will see if it helps :).
>>>
>>
>> It's your prerogative to do what you like, but I feel like the other
>> two alternatives I gave are a bit less intense than what you are
>> proposing, no?
>>
>> It also has the bonus feature of not requiring a non-standard
>> data.table install, which is good if you expect anybody else to use
>> your package.
>>
>> -steve
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/datatable-help/attachments/20130307/62a87548/attachment.html>