[R-pkg-devel] Building my R package: issue when importing two functions with the same name

[Gianmarco Alberti]

I am building a R package, and I am facing an issue caused (as far as I 
understand) by the fact that some functions out of my package rely on two 
fuctions having the same name and coming from 2 different packages:

pROC::roc
spatstat::roc

When checking the package via devtools::check(), I get the following warning:

Warning: replacing previous import ‘spatstat::roc’ by ‘pROC::roc’ when loading 
‘GmAMisc’

Note that both packages are listed among the Imports in my package's 
DESCRIPTION file, and that (within my functions) I have actually used 
spatstat::roc and pROC::roc where needed.

I have done some web-search but I could not locate any workaround that actually 
fixes my issue.

Do you have any suggestion on the matter?

**
Dr Gianmarco Alberti (PhD)
(currently)
Research Support Officer II
Department of Classics and Archaeology
Faculty of Arts
University of Malta

(starting from 3rd September 2018)
Lecturer in Spatial Forensics
Department of Criminology
Faculty for Social Wellbeing
University of Malta
https://www.researchgate.net/profile/Gianmarco_Alberti4
http://cainarchaeology.weebly.com/
**


[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Building my R package: issue when importing two functions with the same name

[Hugh Parsonage]

Does your package import or depend on 'GmAMisc'? This package appears
to Depend on both spatstat and pROC.

Alternatively you have imported both packages in your NAMESPACE.

If neither of these clues help, could you post your DESCRIPTION and
NAMESPACE files? Probably all we'd need.



On 6 August 2018 at 06:21, Gianmarco Alberti  wrote:
> I am building a R package, and I am facing an issue caused (as far as I 
> understand) by the fact that some functions out of my package rely on two 
> fuctions having the same name and coming from 2 different packages:
>
> pROC::roc
> spatstat::roc
>
> When checking the package via devtools::check(), I get the following warning:
>
> Warning: replacing previous import ‘spatstat::roc’ by ‘pROC::roc’ when 
> loading ‘GmAMisc’
>
> Note that both packages are listed among the Imports in my package's 
> DESCRIPTION file, and that (within my functions) I have actually used 
> spatstat::roc and pROC::roc where needed.
>
> I have done some web-search but I could not locate any workaround that 
> actually fixes my issue.
>
> Do you have any suggestion on the matter?
>
> **
> Dr Gianmarco Alberti (PhD)
> (currently)
> Research Support Officer II
> Department of Classics and Archaeology
> Faculty of Arts
> University of Malta
>
> (starting from 3rd September 2018)
> Lecturer in Spatial Forensics
> Department of Criminology
> Faculty for Social Wellbeing
> University of Malta
> https://www.researchgate.net/profile/Gianmarco_Alberti4
> http://cainarchaeology.weebly.com/
> **
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Building my R package: issue when importing two functions with the same name

[Iñaki Úcar]

El mar., 7 ago. 2018 a las 9:32, Gianmarco Alberti
() escribió:
>
> I am building a R package, and I am facing an issue caused (as far as I 
> understand) by the fact that some functions out of my package rely on two 
> fuctions having the same name and coming from 2 different packages:
>
> pROC::roc
> spatstat::roc
>
> When checking the package via devtools::check(), I get the following warning:
>
> Warning: replacing previous import ‘spatstat::roc’ by ‘pROC::roc’ when 
> loading ‘GmAMisc’
>
> Note that both packages are listed among the Imports in my package's 
> DESCRIPTION file, and that (within my functions) I have actually used 
> spatstat::roc and pROC::roc where needed.

I see:

Depends: R (>= 3.4.0), ggplot2, ggrepel, rgdal, rgeos, raster, sp,
spatstat, maptools, spatialEco, dismo, pROC, kimisc, corrplot,
InPosition, lsr, gridExtra, caTools, plyr, classInt, coin, DescTools,
rWind, shape, rworldmap, cluster, RcmdrMisc, gdistance, Hmisc

In general, it is not a good idea to depend on so many packages,
because what "Depends" do is to load and attach packages. Among other
issues, there is one that you are already experimenting: "roc" is
exported both by "spatstat" and "pROC", so one masks the other.

The solution is to list them under "Imports" instead of "Depends". In
fact, my advice is to put as many packages as possible under
"Imports". Keep in "Depends" only those you would load and attach
anyway when working with your package, because you need all the
functions along with the ones your package exports. For the rest of
them, just use them as package::function to avoid this kind of
problem, and reexport functions selectively if needed.

Iñaki

PS: I'm taking a look at other packages and I see that you always use
"Depends" and never "Imports". My general advice is against this
practice. Moreover, from the "Writing R Extensions" manual:

"Field ‘Depends’ should nowadays be used rarely, only for packages
which are intended to be put on the search path to make their
facilities available to the end user (and not to the package itself):
for example it makes sense that a user of package 'latticeExtra' would
want the functions of package 'lattice' made available."

>
> I have done some web-search but I could not locate any workaround that 
> actually fixes my issue.
>
> Do you have any suggestion on the matter?
>
> **
> Dr Gianmarco Alberti (PhD)
> (currently)
> Research Support Officer II
> Department of Classics and Archaeology
> Faculty of Arts
> University of Malta
>
> (starting from 3rd September 2018)
> Lecturer in Spatial Forensics
> Department of Criminology
> Faculty for Social Wellbeing
> University of Malta
> https://www.researchgate.net/profile/Gianmarco_Alberti4
> http://cainarchaeology.weebly.com/
> **
>
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Building my R package: issue when importing two functions with the same name

[Uwe Ligges]

... and even if you are importing from several packages, you should 
import selective via importFrom directoves.


If you need two functions with identical names, import at most one of 
them and rather use pkg::foo syntax to access them.


Best,
Uwe Ligges





On 07.08.2018 10:14, Iñaki Úcar wrote:

El mar., 7 ago. 2018 a las 9:32, Gianmarco Alberti
() escribió:


I am building a R package, and I am facing an issue caused (as far as I 
understand) by the fact that some functions out of my package rely on two 
fuctions having the same name and coming from 2 different packages:

pROC::roc
spatstat::roc

When checking the package via devtools::check(), I get the following warning:

Warning: replacing previous import ‘spatstat::roc’ by ‘pROC::roc’ when loading 
‘GmAMisc’

Note that both packages are listed among the Imports in my package's 
DESCRIPTION file, and that (within my functions) I have actually used 
spatstat::roc and pROC::roc where needed.


I see:

Depends: R (>= 3.4.0), ggplot2, ggrepel, rgdal, rgeos, raster, sp,
spatstat, maptools, spatialEco, dismo, pROC, kimisc, corrplot,
InPosition, lsr, gridExtra, caTools, plyr, classInt, coin, DescTools,
rWind, shape, rworldmap, cluster, RcmdrMisc, gdistance, Hmisc

In general, it is not a good idea to depend on so many packages,
because what "Depends" do is to load and attach packages. Among other
issues, there is one that you are already experimenting: "roc" is
exported both by "spatstat" and "pROC", so one masks the other.

The solution is to list them under "Imports" instead of "Depends". In
fact, my advice is to put as many packages as possible under
"Imports". Keep in "Depends" only those you would load and attach
anyway when working with your package, because you need all the
functions along with the ones your package exports. For the rest of
them, just use them as package::function to avoid this kind of
problem, and reexport functions selectively if needed.

Iñaki

PS: I'm taking a look at other packages and I see that you always use
"Depends" and never "Imports". My general advice is against this
practice. Moreover, from the "Writing R Extensions" manual:

"Field ‘Depends’ should nowadays be used rarely, only for packages
which are intended to be put on the search path to make their
facilities available to the end user (and not to the package itself):
for example it makes sense that a user of package 'latticeExtra' would
want the functions of package 'lattice' made available."



I have done some web-search but I could not locate any workaround that actually 
fixes my issue.

Do you have any suggestion on the matter?

**
Dr Gianmarco Alberti (PhD)
(currently)
Research Support Officer II
Department of Classics and Archaeology
Faculty of Arts
University of Malta

(starting from 3rd September 2018)
Lecturer in Spatial Forensics
Department of Criminology
Faculty for Social Wellbeing
University of Malta
https://www.researchgate.net/profile/Gianmarco_Alberti4
http://cainarchaeology.weebly.com/
**


 [[alternative HTML version deleted]]

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


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



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

Re: [R-pkg-devel] Building my R package: issue when importing two functions with the same name

[Rainer M Krug]

Probably discussed already, but what is the difference between using “::” and 
“ImportFrom”? I usually use ImportFrom and “::” just to make clear, where the 
function is coming from - is this a problem?

Rainer


> On 7 Aug 2018, at 11:14, Uwe Ligges  wrote:
> 
> ... and even if you are importing from several packages, you should import 
> selective via importFrom directoves.
> 
> If you need two functions with identical names, import at most one of them 
> and rather use pkg::foo syntax to access them.
> 
> Best,
> Uwe Ligges
> 
> 
> 
> 
> 
> On 07.08.2018 10:14, Iñaki Úcar wrote:
>> El mar., 7 ago. 2018 a las 9:32, Gianmarco Alberti
>> () escribió:
>>> 
>>> I am building a R package, and I am facing an issue caused (as far as I 
>>> understand) by the fact that some functions out of my package rely on two 
>>> fuctions having the same name and coming from 2 different packages:
>>> 
>>> pROC::roc
>>> spatstat::roc
>>> 
>>> When checking the package via devtools::check(), I get the following 
>>> warning:
>>> 
>>> Warning: replacing previous import ‘spatstat::roc’ by ‘pROC::roc’ when 
>>> loading ‘GmAMisc’
>>> 
>>> Note that both packages are listed among the Imports in my package's 
>>> DESCRIPTION file, and that (within my functions) I have actually used 
>>> spatstat::roc and pROC::roc where needed.
>> I see:
>> Depends: R (>= 3.4.0), ggplot2, ggrepel, rgdal, rgeos, raster, sp,
>> spatstat, maptools, spatialEco, dismo, pROC, kimisc, corrplot,
>> InPosition, lsr, gridExtra, caTools, plyr, classInt, coin, DescTools,
>> rWind, shape, rworldmap, cluster, RcmdrMisc, gdistance, Hmisc
>> In general, it is not a good idea to depend on so many packages,
>> because what "Depends" do is to load and attach packages. Among other
>> issues, there is one that you are already experimenting: "roc" is
>> exported both by "spatstat" and "pROC", so one masks the other.
>> The solution is to list them under "Imports" instead of "Depends". In
>> fact, my advice is to put as many packages as possible under
>> "Imports". Keep in "Depends" only those you would load and attach
>> anyway when working with your package, because you need all the
>> functions along with the ones your package exports. For the rest of
>> them, just use them as package::function to avoid this kind of
>> problem, and reexport functions selectively if needed.
>> Iñaki
>> PS: I'm taking a look at other packages and I see that you always use
>> "Depends" and never "Imports". My general advice is against this
>> practice. Moreover, from the "Writing R Extensions" manual:
>> "Field ‘Depends’ should nowadays be used rarely, only for packages
>> which are intended to be put on the search path to make their
>> facilities available to the end user (and not to the package itself):
>> for example it makes sense that a user of package 'latticeExtra' would
>> want the functions of package 'lattice' made available."
>>> 
>>> I have done some web-search but I could not locate any workaround that 
>>> actually fixes my issue.
>>> 
>>> Do you have any suggestion on the matter?
>>> 
>>> **
>>> Dr Gianmarco Alberti (PhD)
>>> (currently)
>>> Research Support Officer II
>>> Department of Classics and Archaeology
>>> Faculty of Arts
>>> University of Malta
>>> 
>>> (starting from 3rd September 2018)
>>> Lecturer in Spatial Forensics
>>> Department of Criminology
>>> Faculty for Social Wellbeing
>>> University of Malta
>>> https://www.researchgate.net/profile/Gianmarco_Alberti4
>>> http://cainarchaeology.weebly.com/
>>> **
>>> 
>>> 
>>> [[alternative HTML version deleted]]
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

University of Zürich

Cell:   +41 (0)78 630 66 57
email:  rai...@krugs.de
Skype:  RMkrug

PGP: 0x0F52F982





signature.asc
Description: Message signed with OpenPGP
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Building my R package: issue when importing two functions with the same name

[Gianmarco Alberti]

Thanks indeed for the clarification.

I eventually managed to solve the issue. By the way, I have moved of the 
packages my package relies on to the Imports section.
I have checked my package and it returned no error nor note nor warning.
I have submitted it to CRAN.

Thanks for your prompt feedback.

Best
Gm A


**
Dr Gianmarco Alberti (PhD)
(currently)
Research Support Officer II
Department of Classics and Archaeology
Faculty of Arts
University of Malta

(starting from 3rd September 2018)
Lecturer in Spatial Forensics
Department of Criminology
Faculty for Social Wellbeing
University of Malta
https://www.researchgate.net/profile/Gianmarco_Alberti4
http://cainarchaeology.weebly.com/
**

Il 7 ago 2018, 11:14 +0200, Uwe Ligges , ha 
scritto:
> ... and even if you are importing from several packages, you should
> import selective via importFrom directoves.
>
> If you need two functions with identical names, import at most one of
> them and rather use pkg::foo syntax to access them.
>
> Best,
> Uwe Ligges
>
>
>
>
>
> On 07.08.2018 10:14, Iñaki Úcar wrote:
> > El mar., 7 ago. 2018 a las 9:32, Gianmarco Alberti
> > () escribió:
> > >
> > > I am building a R package, and I am facing an issue caused (as far as I 
> > > understand) by the fact that some functions out of my package rely on two 
> > > fuctions having the same name and coming from 2 different packages:
> > >
> > > pROC::roc
> > > spatstat::roc
> > >
> > > When checking the package via devtools::check(), I get the following 
> > > warning:
> > >
> > > Warning: replacing previous import ‘spatstat::roc’ by ‘pROC::roc’ when 
> > > loading ‘GmAMisc’
> > >
> > > Note that both packages are listed among the Imports in my package's 
> > > DESCRIPTION file, and that (within my functions) I have actually used 
> > > spatstat::roc and pROC::roc where needed.
> >
> > I see:
> >
> > Depends: R (>= 3.4.0), ggplot2, ggrepel, rgdal, rgeos, raster, sp,
> > spatstat, maptools, spatialEco, dismo, pROC, kimisc, corrplot,
> > InPosition, lsr, gridExtra, caTools, plyr, classInt, coin, DescTools,
> > rWind, shape, rworldmap, cluster, RcmdrMisc, gdistance, Hmisc
> >
> > In general, it is not a good idea to depend on so many packages,
> > because what "Depends" do is to load and attach packages. Among other
> > issues, there is one that you are already experimenting: "roc" is
> > exported both by "spatstat" and "pROC", so one masks the other.
> >
> > The solution is to list them under "Imports" instead of "Depends". In
> > fact, my advice is to put as many packages as possible under
> > "Imports". Keep in "Depends" only those you would load and attach
> > anyway when working with your package, because you need all the
> > functions along with the ones your package exports. For the rest of
> > them, just use them as package::function to avoid this kind of
> > problem, and reexport functions selectively if needed.
> >
> > Iñaki
> >
> > PS: I'm taking a look at other packages and I see that you always use
> > "Depends" and never "Imports". My general advice is against this
> > practice. Moreover, from the "Writing R Extensions" manual:
> >
> > "Field ‘Depends’ should nowadays be used rarely, only for packages
> > which are intended to be put on the search path to make their
> > facilities available to the end user (and not to the package itself):
> > for example it makes sense that a user of package 'latticeExtra' would
> > want the functions of package 'lattice' made available."
> >
> > >
> > > I have done some web-search but I could not locate any workaround that 
> > > actually fixes my issue.
> > >
> > > Do you have any suggestion on the matter?
> > >
> > > **
> > > Dr Gianmarco Alberti (PhD)
> > > (currently)
> > > Research Support Officer II
> > > Department of Classics and Archaeology
> > > Faculty of Arts
> > > University of Malta
> > >
> > > (starting from 3rd September 2018)
> > > Lecturer in Spatial Forensics
> > > Department of Criminology
> > > Faculty for Social Wellbeing
> > > University of Malta
> > > https://www.researchgate.net/profile/Gianmarco_Alberti4
> > > http://cainarchaeology.weebly.com/
> > > **
> > >
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > __
> > > R-package-devel@r-project.org mailing list
> > > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Building my R package: issue when importing two functions with the same name

[Duncan Murdoch]

On 05/08/2018 4:21 PM, Gianmarco Alberti wrote:

I am building a R package, and I am facing an issue caused (as far as I 
understand) by the fact that some functions out of my package rely on two 
fuctions having the same name and coming from 2 different packages:

pROC::roc
spatstat::roc



As Iñaki pointed out, the main issue is that you should be using Import 
rather than Depends.  But I didn't see mentioned the fact that the 
NAMESPACE file can rename a function when you import it, e.g.


importFrom(pROC, pROCroc = roc)
importFrom(spatstat, spatstatroc = roc)

Now in your own functions you can use pROCroc() or spatstatroc() and 
they won't conflict.


(I was going to point you to the documentation for this, but I am not 
sure it is properly documented anywhere.)


Duncan Murdoch


When checking the package via devtools::check(), I get the following warning:

Warning: replacing previous import ‘spatstat::roc’ by ‘pROC::roc’ when loading 
‘GmAMisc’

Note that both packages are listed among the Imports in my package's 
DESCRIPTION file, and that (within my functions) I have actually used 
spatstat::roc and pROC::roc where needed.

I have done some web-search but I could not locate any workaround that actually 
fixes my issue.

Do you have any suggestion on the matter?

**
Dr Gianmarco Alberti (PhD)
(currently)
Research Support Officer II
Department of Classics and Archaeology
Faculty of Arts
University of Malta

(starting from 3rd September 2018)
Lecturer in Spatial Forensics
Department of Criminology
Faculty for Social Wellbeing
University of Malta
https://www.researchgate.net/profile/Gianmarco_Alberti4
http://cainarchaeology.weebly.com/
**


[[alternative HTML version deleted]]

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



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

Re: [R-pkg-devel] Building my R package: issue when importing two functions with the same name

[Rainer M Krug]

This is very useful - didn’t know that.

Thanks

Rainer


> On 7 Aug 2018, at 13:11, Duncan Murdoch  wrote:
> 
> On 05/08/2018 4:21 PM, Gianmarco Alberti wrote:
>> I am building a R package, and I am facing an issue caused (as far as I 
>> understand) by the fact that some functions out of my package rely on two 
>> fuctions having the same name and coming from 2 different packages:
>> pROC::roc
>> spatstat::roc
> 
> As Iñaki pointed out, the main issue is that you should be using Import 
> rather than Depends.  But I didn't see mentioned the fact that the NAMESPACE 
> file can rename a function when you import it, e.g.
> 
> importFrom(pROC, pROCroc = roc)
> importFrom(spatstat, spatstatroc = roc)
> 
> Now in your own functions you can use pROCroc() or spatstatroc() and they 
> won't conflict.
> 
> (I was going to point you to the documentation for this, but I am not sure it 
> is properly documented anywhere.)
> 
> Duncan Murdoch
> 
>> When checking the package via devtools::check(), I get the following warning:
>> Warning: replacing previous import ‘spatstat::roc’ by ‘pROC::roc’ when 
>> loading ‘GmAMisc’
>> Note that both packages are listed among the Imports in my package's 
>> DESCRIPTION file, and that (within my functions) I have actually used 
>> spatstat::roc and pROC::roc where needed.
>> I have done some web-search but I could not locate any workaround that 
>> actually fixes my issue.
>> Do you have any suggestion on the matter?
>> **
>> Dr Gianmarco Alberti (PhD)
>> (currently)
>> Research Support Officer II
>> Department of Classics and Archaeology
>> Faculty of Arts
>> University of Malta
>> (starting from 3rd September 2018)
>> Lecturer in Spatial Forensics
>> Department of Criminology
>> Faculty for Social Wellbeing
>> University of Malta
>> https://www.researchgate.net/profile/Gianmarco_Alberti4
>> http://cainarchaeology.weebly.com/
>> **
>>  [[alternative HTML version deleted]]
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

University of Zürich

Cell:   +41 (0)78 630 66 57
email:  rai...@krugs.de
Skype:  RMkrug

PGP: 0x0F52F982





signature.asc
Description: Message signed with OpenPGP
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Building my R package: issue when importing two functions with the same name

[Gianmarco Alberti]

@Duncan:

Extremely interesting...thanks.

Gm


**
Dr Gianmarco Alberti (PhD)
(currently)
Research Support Officer II
Department of Classics and Archaeology
Faculty of Arts
University of Malta

(starting from 3rd September 2018)
Lecturer in Spatial Forensics
Department of Criminology
Faculty for Social Wellbeing
University of Malta
https://www.researchgate.net/profile/Gianmarco_Alberti4
http://cainarchaeology.weebly.com/
**

Il 7 ago 2018, 13:11 +0200, Duncan Murdoch , ha 
scritto:
> On 05/08/2018 4:21 PM, Gianmarco Alberti wrote:
> > I am building a R package, and I am facing an issue caused (as far as I 
> > understand) by the fact that some functions out of my package rely on two 
> > fuctions having the same name and coming from 2 different packages:
> >
> > pROC::roc
> > spatstat::roc
> >
>
> As Iñaki pointed out, the main issue is that you should be using Import
> rather than Depends. But I didn't see mentioned the fact that the
> NAMESPACE file can rename a function when you import it, e.g.
>
> importFrom(pROC, pROCroc = roc)
> importFrom(spatstat, spatstatroc = roc)
>
> Now in your own functions you can use pROCroc() or spatstatroc() and
> they won't conflict.
>
> (I was going to point you to the documentation for this, but I am not
> sure it is properly documented anywhere.)
>
> Duncan Murdoch
>
> > When checking the package via devtools::check(), I get the following 
> > warning:
> >
> > Warning: replacing previous import ‘spatstat::roc’ by ‘pROC::roc’ when 
> > loading ‘GmAMisc’
> >
> > Note that both packages are listed among the Imports in my package's 
> > DESCRIPTION file, and that (within my functions) I have actually used 
> > spatstat::roc and pROC::roc where needed.
> >
> > I have done some web-search but I could not locate any workaround that 
> > actually fixes my issue.
> >
> > Do you have any suggestion on the matter?
> >
> > **
> > Dr Gianmarco Alberti (PhD)
> > (currently)
> > Research Support Officer II
> > Department of Classics and Archaeology
> > Faculty of Arts
> > University of Malta
> >
> > (starting from 3rd September 2018)
> > Lecturer in Spatial Forensics
> > Department of Criminology
> > Faculty for Social Wellbeing
> > University of Malta
> > https://www.researchgate.net/profile/Gianmarco_Alberti4
> > http://cainarchaeology.weebly.com/
> > **
> >
> >
> > [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] Run garbage collector when too many open files

[Jan van der Laan]

In my package I open handles to temporary files from c++, handles to 
them are returned to R through vptr objects. The files are deleted then 
the corresponding R-object is deleted and the garbage collector runs:


a <- lvec(10, "integer")
rm(a)

Then when the garbage collector runs the file is deleted. However, on 
some platforms (probably with lower limits on the maximum number of file 
handles a process can have open), I run into the problem that the 
garbage collector doesn't run often enough. In this case that means that 
another package of mine using this package generates an error when its 
tests are run.


The simplest solution is to add some calls to gc() in my tests. But a 
more general/automatic solution would be nice.


I thought about something in the lines of

robust_lvec <- function(...) {
  tryCatch({
lvec(...)
  }, error = function(e) {
gc()
lvec(...) # duplicated code
  })
}

e.g. try to open a file, when that fails call the garbage collector and 
try again. However, this introduces duplicated code (in this case only 
one line, but that can be more), and doesn't help if it is another 
function that tries to open a file.


Is there a better solution?

Thanks!

Jan

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

Re: [R-pkg-devel] Run garbage collector when too many open files

[Uwe Ligges]

Why not add functionality that allows to delete object + runs cleanup code?

Best,
Uwe Ligges



On 07.08.2018 14:26, Jan van der Laan wrote:



In my package I open handles to temporary files from c++, handles to 
them are returned to R through vptr objects. The files are deleted then 
the corresponding R-object is deleted and the garbage collector runs:


a <- lvec(10, "integer")
rm(a)

Then when the garbage collector runs the file is deleted. However, on 
some platforms (probably with lower limits on the maximum number of file 
handles a process can have open), I run into the problem that the 
garbage collector doesn't run often enough. In this case that means that 
another package of mine using this package generates an error when its 
tests are run.


The simplest solution is to add some calls to gc() in my tests. But a 
more general/automatic solution would be nice.


I thought about something in the lines of

robust_lvec <- function(...) {
   tryCatch({
     lvec(...)
   }, error = function(e) {
     gc()
     lvec(...) # duplicated code
   })
}

e.g. try to open a file, when that fails call the garbage collector and 
try again. However, this introduces duplicated code (in this case only 
one line, but that can be more), and doesn't help if it is another 
function that tries to open a file.


Is there a better solution?

Thanks!

Jan

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


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

[R-pkg-devel] Can Submission Failure

[Ossenbruggen, Paul]

I am new to CRAN submissions and need assistance.

I received this set of error messages previously. I removed all these hidden 
files before resubmitting my package. They are back.
Question #1 How do I prevent this this?

PJO:Desktop PJO$ tar -zcvf Basic.tar.gz Basic
Found the following hidden files and directories:

  .DS_Store
  .RData
  .Rhistory
  ._NAMESPACE
  .gitignore
  .travis.yml
  R/.DS_Store
  R/._brkdelay.R
  R/._brkdelay3.R
  R/._brktrials3.R
  R/._brktrials3setup.R
  R/._merge.R
  R/._merge3.R
  R/._mergedemo.R
  R/._plotdesire3.R
  R/._plotmerge3.R
  R/._run.R
  R/._trajectoryab3.R
  R/._tuxvfix3.R
  R/._vehid.R
  R/._xabmerge.R
  R/._xabmerge3.R
  data/.DS_Store
  data/.Rapp.history
  man/.Rapp.history
  vignettes/._cartools.Rmd
  vignettes/.gitignore
  .Rproj.user
  .git


Finding an answer to this question will be a big help.


I performed R CMD check and devtools::build_win() before I submitted the above. 
For completeness, here are my submit statements.


From: CRAN submission 
mailto:cran-sysad...@xmpalantir.wu.ac.at>>
Subject: CRAN submission Basic 0.1.0
Date: August 7, 2018 at 11:29:34 AM EDT
To: CRAN mailto:cran-submissi...@r-project.org>>
Reply-To: Paul J. Ossenbruggen mailto:p...@unh.edu>>


The maintainer confirms that he or she
has read and agrees to the CRAN policies.

Submitter's comment: This submittal passes these checks. However, I am
 uncertain that my submittal succeed. See #1, #2, #3,
 #4 and #5.

R CMD check results
0 errors | 0
 warnings | 0 notes
R CMD check succeeded


 devtools::build_win()
Building windows version of
 cartools for R-devel with
 win-builder.r-project.org.

#1. Warning:
 ‘inst/doc’ files
   ‘cartools.Rmd’,
 ‘cartools.html’, ‘cartools.R’
 ignored as
 vignettes have been rebuilt.
 Run R CMD build with
 --no-build-vignettes to prevent rebuilding.
*
 checking for LF line-endings in source and make files
 and shell scripts
* checking for empty or unneeded
 directories
* looking to see if a
 ‘data/datalist’ file should be added
#2.
*
 building ‘cartools_0.1.0.tar.gz’
I don't understand what this file is for. I am uploading:  Basic.tar.gz.

#3
I have instructed the following
 folder to be ignored:  .Rproj.user
It is not ignored
 in GitHub. It contains items that I did not
 create.
This does not seem correct,

#4. I
 receievd a win-builder email stating:
Possibly
 mis-spelled words in DESCRIPTION: cartools
 (3:8)
Unknown, possibly mis-spelled, fields in
 DESCRIPTION: 'Remotes'
The above items are
 false/postives.

I don't understand the following
 statement.
The Title field is just the package name:
 provide a real title.

#5. I am a subscriber but my
 questions to r-packages-devel bounce.





=

Original content of DESCRIPTION file:

Package: Basic
Type: Package
Title: CARTOOLS Package
Version: 0.1.0
Author: person("Paul", "Ossenbruggen", email = 
"p...@unh.edu", role = c("aut", "cre"))
Maintainer: "Paul J. Ossenbruggen" mailto:p...@unh.edu>>
Description: The cartools package is designed for college students studying 
transportation engineering and for transportation professionals and researchers 
interested in understanding the complex relationships associated with freeway 
performance and traffic breakdown. Emphasis is placed on: (1) Traffic noise or 
volatility; (2) Driver behavior and safety; and (3) Stochastic modeling, models 
that explain breakdown and performance.
License: MIT + file LICENSE
Encoding: UTF-8
LazyData: true
Depends: R (>= 2.10)
RoxygenNote: 6.1.0
Remotes: pjossenbruggen/Basic
Imports:
   animation,
   devtools,
   dplyr,
   gapminder,
   ggplot2,
   graphics,
   grDevices,
   knitr,
   rlist,
   rmarkdown,
   roxygen2,
   sde,
   shiny,
   stats,
   tidyverse,
   usethis,
   utils
Suggests:
VignetteBuilder: knitr









[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Can Submission Failure

[Zhian Kamvar]

Copy this output into a file called .Rbuildignore at the top of the directory:

>  .DS_Store
>  .RData
>  .Rhistory
>  ._*
>  .gitignore
>  .travis.yml
>  R/.DS_Store
>  R/._*
>  data/.DS_Store
>  data/.Rapp.history
>  man/.Rapp.history
>  vignettes/._*
>  vignettes/.gitignore
>  .Rproj.user
>  .git

Hope that helps,
Zhian

> On Aug 7, 2018, at 17:27 , Ossenbruggen, Paul  
> wrote:
> 
> I am new to CRAN submissions and need assistance.
> 
> I received this set of error messages previously. I removed all these hidden 
> files before resubmitting my package. They are back.
> Question #1 How do I prevent this this?
> 
> PJO:Desktop PJO$ tar -zcvf Basic.tar.gz Basic
> Found the following hidden files and directories:
> 
>  .DS_Store
>  .RData
>  .Rhistory
>  ._NAMESPACE
>  .gitignore
>  .travis.yml
>  R/.DS_Store
>  R/._brkdelay.R
>  R/._brkdelay3.R
>  R/._brktrials3.R
>  R/._brktrials3setup.R
>  R/._merge.R
>  R/._merge3.R
>  R/._mergedemo.R
>  R/._plotdesire3.R
>  R/._plotmerge3.R
>  R/._run.R
>  R/._trajectoryab3.R
>  R/._tuxvfix3.R
>  R/._vehid.R
>  R/._xabmerge.R
>  R/._xabmerge3.R
>  data/.DS_Store
>  data/.Rapp.history
>  man/.Rapp.history
>  vignettes/._cartools.Rmd
>  vignettes/.gitignore
>  .Rproj.user
>  .git
> 
> 
> Finding an answer to this question will be a big help.
> 
> 
> I performed R CMD check and devtools::build_win() before I submitted the 
> above. For completeness, here are my submit statements.
> 
> 
> From: CRAN submission 
> mailto:cran-sysad...@xmpalantir.wu.ac.at>>
> Subject: CRAN submission Basic 0.1.0
> Date: August 7, 2018 at 11:29:34 AM EDT
> To: CRAN 
> mailto:cran-submissi...@r-project.org>>
> Reply-To: Paul J. Ossenbruggen mailto:p...@unh.edu>>
> 
> 
> The maintainer confirms that he or she
> has read and agrees to the CRAN policies.
> 
> Submitter's comment: This submittal passes these checks. However, I am
> uncertain that my submittal succeed. See #1, #2, #3,
> #4 and #5.
> 
> R CMD check results
> 0 errors | 0
> warnings | 0 notes
> R CMD check succeeded
> 
> 
> devtools::build_win()
> Building windows version of
> cartools for R-devel with
> win-builder.r-project.org.
> 
> #1. Warning:
> ‘inst/doc’ files
>   ‘cartools.Rmd’,
> ‘cartools.html’, ‘cartools.R’
> ignored as
> vignettes have been rebuilt.
> Run R CMD build with
> --no-build-vignettes to prevent rebuilding.
> *
> checking for LF line-endings in source and make files
> and shell scripts
> * checking for empty or unneeded
> directories
> * looking to see if a
> ‘data/datalist’ file should be added
> #2.
> *
> building ‘cartools_0.1.0.tar.gz’
> I don't understand what this file is for. I am uploading:  Basic.tar.gz.
> 
> #3
> I have instructed the following
> folder to be ignored:  .Rproj.user
> It is not ignored
> in GitHub. It contains items that I did not
> create.
> This does not seem correct,
> 
> #4. I
> receievd a win-builder email stating:
> Possibly
> mis-spelled words in DESCRIPTION: cartools
> (3:8)
> Unknown, possibly mis-spelled, fields in
> DESCRIPTION: 'Remotes'
> The above items are
> false/postives.
> 
> I don't understand the following
> statement.
> The Title field is just the package name:
> provide a real title.
> 
> #5. I am a subscriber but my
> questions to r-packages-devel bounce.
> 
> 
> 
> 
> 
> =
> 
> Original content of DESCRIPTION file:
> 
> Package: Basic
> Type: Package
> Title: CARTOOLS Package
> Version: 0.1.0
> Author: person("Paul", "Ossenbruggen", email = 
> "p...@unh.edu", role = c("aut", "cre"))
> Maintainer: "Paul J. Ossenbruggen" mailto:p...@unh.edu>>
> Description: The cartools package is designed for college students studying 
> transportation engineering and for transportation professionals and 
> researchers interested in understanding the complex relationships associated 
> with freeway performance and traffic breakdown. Emphasis is placed on: (1) 
> Traffic noise or volatility; (2) Driver behavior and safety; and (3) 
> Stochastic modeling, models that explain breakdown and performance.
> License: MIT + file LICENSE
> Encoding: UTF-8
> LazyData: true
> Depends: R (>= 2.10)
> RoxygenNote: 6.1.0
> Remotes: pjossenbruggen/Basic
> Imports:
>   animation,
>   devtools,
>   dplyr,
>   gapminder,
>   ggplot2,
>   graphics,
>   grDevices,
>   knitr,
>   rlist,
>   rmarkdown,
>   roxygen2,
>   sde,
>   shiny,
>   stats,
>   tidyverse,
>   usethis,
>   utils
> Suggests:
> VignetteBuilder: knitr
> 
> 
> 
> 
> 
> 
> 
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



signature.asc
Description: Message signed with OpenPGP
__
R-package-devel@r-project.org mailing list
https://stat.ethz

Re: [R-pkg-devel] Can Submission Failure

[Dirk Eddelbuettel]

On 7 August 2018 at 16:27, Ossenbruggen, Paul wrote:
| I am new to CRAN submissions and need assistance.
| 
| I received this set of error messages previously. I removed all these hidden 
files before resubmitting my package. They are back.
| Question #1 How do I prevent this this?

1. (Optional) Delete them. Write a script named cleanup with executable mode
with calls rm on them. The each build will remove them in its cleanup phase.

2. Add them to .Rbuildignore. See Writing R Extensions for details.

Dirk
 
| PJO:Desktop PJO$ tar -zcvf Basic.tar.gz Basic
| Found the following hidden files and directories:
| 
|   .DS_Store
|   .RData
|   .Rhistory
|   ._NAMESPACE
|   .gitignore
|   .travis.yml
|   R/.DS_Store
|   R/._brkdelay.R
|   R/._brkdelay3.R
|   R/._brktrials3.R
|   R/._brktrials3setup.R
|   R/._merge.R
|   R/._merge3.R
|   R/._mergedemo.R
|   R/._plotdesire3.R
|   R/._plotmerge3.R
|   R/._run.R
|   R/._trajectoryab3.R
|   R/._tuxvfix3.R
|   R/._vehid.R
|   R/._xabmerge.R
|   R/._xabmerge3.R
|   data/.DS_Store
|   data/.Rapp.history
|   man/.Rapp.history
|   vignettes/._cartools.Rmd
|   vignettes/.gitignore
|   .Rproj.user
|   .git
| 
| 
| Finding an answer to this question will be a big help.
| 
| 
| I performed R CMD check and devtools::build_win() before I submitted the 
above. For completeness, here are my submit statements.
| 
| 

| From: CRAN submission 
mailto:cran-sysad...@xmpalantir.wu.ac.at>>
| Subject: CRAN submission Basic 0.1.0
| Date: August 7, 2018 at 11:29:34 AM EDT
| To: CRAN 
mailto:cran-submissi...@r-project.org>>
| Reply-To: Paul J. Ossenbruggen mailto:p...@unh.edu>>
| 
| 
| The maintainer confirms that he or she
| has read and agrees to the CRAN policies.
| 
| Submitter's comment: This submittal passes these checks. However, I am
|  uncertain that my submittal succeed. See #1, #2, #3,
|  #4 and #5.
| 
| R CMD check results
| 0 errors | 0
|  warnings | 0 notes
| R CMD check succeeded
| 
| 
|  devtools::build_win()
| Building windows version of
|  cartools for R-devel with
|  win-builder.r-project.org.
| 
| #1. Warning:
|  ‘inst/doc’ files
|‘cartools.Rmd’,
|  ‘cartools.html’, ‘cartools.R’
|  ignored as
|  vignettes have been rebuilt.
|  Run R CMD build with
|  --no-build-vignettes to prevent rebuilding.
| *
|  checking for LF line-endings in source and make files
|  and shell scripts
| * checking for empty or unneeded
|  directories
| * looking to see if a
|  ‘data/datalist’ file should be added
| #2.
| *
|  building ‘cartools_0.1.0.tar.gz’
| I don't understand what this file is for. I am uploading:  Basic.tar.gz.
| 
| #3
| I have instructed the following
|  folder to be ignored:  .Rproj.user
| It is not ignored
|  in GitHub. It contains items that I did not
|  create.
| This does not seem correct,
| 
| #4. I
|  receievd a win-builder email stating:
| Possibly
|  mis-spelled words in DESCRIPTION: cartools
|  (3:8)
| Unknown, possibly mis-spelled, fields in
|  DESCRIPTION: 'Remotes'
| The above items are
|  false/postives.
| 
| I don't understand the following
|  statement.
| The Title field is just the package name:
|  provide a real title.
| 
| #5. I am a subscriber but my
|  questions to r-packages-devel bounce.
| 
| 
| 
| 
| 
| =
| 
| Original content of DESCRIPTION file:
| 
| Package: Basic
| Type: Package
| Title: CARTOOLS Package
| Version: 0.1.0
| Author: person("Paul", "Ossenbruggen", email = 
"p...@unh.edu", role = c("aut", "cre"))
| Maintainer: "Paul J. Ossenbruggen" mailto:p...@unh.edu>>
| Description: The cartools package is designed for college students studying 
transportation engineering and for transportation professionals and researchers 
interested in understanding the complex relationships associated with freeway 
performance and traffic breakdown. Emphasis is placed on: (1) Traffic noise or 
volatility; (2) Driver behavior and safety; and (3) Stochastic modeling, models 
that explain breakdown and performance.
| License: MIT + file LICENSE
| Encoding: UTF-8
| LazyData: true
| Depends: R (>= 2.10)
| RoxygenNote: 6.1.0
| Remotes: pjossenbruggen/Basic
| Imports:
|animation,
|devtools,
|dplyr,
|gapminder,
|ggplot2,
|graphics,
|grDevices,
|knitr,
|rlist,
|rmarkdown,
|roxygen2,
|sde,
|shiny,
|stats,
|tidyverse,
|usethis,
|utils
| Suggests:
| VignetteBuilder: knitr
| 
| 
| 
| 
| 
| 
| 
| 
| 
|   [[alternative HTML version deleted]]
| 
| __
| R-package-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

[R-pkg-devel] CRAN questions

[Ossenbruggen, Paul]

Hello,

I believe the missed spelled words are false/positives, but I am new to R 
package development and uncertain if these Notes are will cause rejection:


Possibly mis-spelled words in DESCRIPTION:
  cartools (3:8)

Unknown, possibly mis-spelled, fields in DESCRIPTION:
  ‘Remotes'


 The following Note may be serious. I would address it but I cannot decipher 
its meaning. My best guess is that the package name, “cartools” does not match 
“Basic.tar.gz”.


The Title field is just the package name: provide a real title.

 Guidance will be appreciated.

Thanks,


Paul

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] CRAN questions

[Uwe Ligges]

On 07.08.2018 20:07, Ossenbruggen, Paul wrote:

Hello,

I believe the missed spelled words are false/positives, but I am new to R 
package development and uncertain if these Notes are will cause rejection:


Possibly mis-spelled words in DESCRIPTION:
   cartools (3:8)



Software names (only) should be single quotes in Title and Description 
fields.





Unknown, possibly mis-spelled, fields in DESCRIPTION:
   ‘Remotes'


Please get rid of that field for CRAN submissions.





  The following Note may be serious. I would address it but I cannot decipher 
its meaning. My best guess is that the package name, “cartools” does not match 
“Basic.tar.gz”.


Basic.tar.gz can't be a valid filename prodiced by R CMD build.

R CMD build will use the package name and version number for the name of 
the tarball.






The Title field is just the package name: provide a real title.


Please provide a name

Package:

and a title in

Title:


Where the title can be a bit more descriptive than the name, of course.

Look at examples what other packages do.

Best,
Uwe Ligges






  Guidance will be appreciated.

Thanks,


Paul

[[alternative HTML version deleted]]

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



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

Re: [R-pkg-devel] CRAN questions

[David Winsemius]

On my mail client the two “quotes” are not matching. One appears vertical and 
the other slightly slanting. 

Sent from my iPhone (which could mean I’m seeing an artifact arising in 
Cupertino. )

David

> On Aug 7, 2018, at 11:11 AM, Uwe Ligges  
> wrote:
> 
> 
> 
>> On 07.08.2018 20:07, Ossenbruggen, Paul wrote:
>> Hello,
>> I believe the missed spelled words are false/positives, but I am new to R 
>> package development and uncertain if these Notes are will cause rejection:
>> Possibly mis-spelled words in DESCRIPTION:
>>   cartools (3:8)
> 
> 
> Software names (only) should be single quotes in Title and Description fields.
> 
> 
>> Unknown, possibly mis-spelled, fields in DESCRIPTION:
>>   ‘Remotes'
> 
> Please get rid of that field for CRAN submissions.
> 
> 
> 
>>  The following Note may be serious. I would address it but I cannot decipher 
>> its meaning. My best guess is that the package name, “cartools” does not 
>> match “Basic.tar.gz”.
> 
> Basic.tar.gz can't be a valid filename prodiced by R CMD build.
> 
> R CMD build will use the package name and version number for the name of the 
> tarball.
> 
> 
>> The Title field is just the package name: provide a real title.
> 
> Please provide a name
> 
> Package:
> 
> 
>> On 07.08.2018 20:07, Ossenbruggen, Paul wrote:
>> Hello,
>> I believe the missed spelled words are false/positives, but I am new to R 
>> package development and uncertain if these Notes are will cause rejection:
>> Possibly mis-spelled words in DESCRIPTION:
>>   cartools (3:8)
> 
> 
> Software names (only) should be single quotes in Title and Description fields.
> 
> 
>> Unknown, possibly mis-spelled, fields in DESCRIPTION:
>>   ‘Remotes'
> 
> Please get rid of that field for CRAN submissions.
> 
> 
> 
>>  The following Note may be serious. I would address it but I cannot decipher 
>> its meaning. My best guess is that the package name, “cartools” does not 
>> match “Basic.tar.gz”.
> 
> Basic.tar.gz can't be a valid filename prodiced by R CMD build.
> 
> R CMD build will use the package name and version number for the name of the 
> tarball.
> 
> 
>> The Title field is just the package name: provide a real title.
> 
> Please provide a name
> 
> Package:
> 
> and a title in
> 
> Title:
> 
> 
> Where the title can be a bit more descriptive than the name, of course.
> 
> Look at examples what other packages do.
> 
> Best,
> Uwe Ligges
> 
> 
> 
> 
> 
>>  Guidance will be appreciated.
>> Thanks,
>> Paul
>>[[alternative HTML version deleted]]
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] Can Submission Failure

[Duncan Murdoch]

On 07/08/2018 12:27 PM, Ossenbruggen, Paul wrote:

I am new to CRAN submissions and need assistance.

I received this set of error messages previously. I removed all these hidden 
files before resubmitting my package. They are back.
Question #1 How do I prevent this this?

PJO:Desktop PJO$ tar -zcvf Basic.tar.gz Basic
Found the following hidden files and directories:

   .DS_Store
   .RData
   .Rhistory
   ._NAMESPACE
   .gitignore
   .travis.yml
   R/.DS_Store
   R/._brkdelay.R
   R/._brkdelay3.R
   R/._brktrials3.R
   R/._brktrials3setup.R
   R/._merge.R
   R/._merge3.R
   R/._mergedemo.R
   R/._plotdesire3.R
   R/._plotmerge3.R
   R/._run.R
   R/._trajectoryab3.R
   R/._tuxvfix3.R
   R/._vehid.R
   R/._xabmerge.R
   R/._xabmerge3.R
   data/.DS_Store
   data/.Rapp.history
   man/.Rapp.history
   vignettes/._cartools.Rmd
   vignettes/.gitignore
   .Rproj.user
   .git


Finding an answer to this question will be a big help.


I performed R CMD check and devtools::build_win() before I submitted the above. 
For completeness, here are my submit statements.


You are doing it wrong.  You should not be using tar to build your 
tarball, you should let R do it.


I don't know exactly what devtools::build_win() does to build the 
tarball, but it then sends it to WinBuilder:  you don't need to do that 
for a CRAN submission.


Duncan Murdoch




From: CRAN submission 
mailto:cran-sysad...@xmpalantir.wu.ac.at>>
Subject: CRAN submission Basic 0.1.0
Date: August 7, 2018 at 11:29:34 AM EDT
To: CRAN mailto:cran-submissi...@r-project.org>>
Reply-To: Paul J. Ossenbruggen mailto:p...@unh.edu>>


The maintainer confirms that he or she
has read and agrees to the CRAN policies.

Submitter's comment: This submittal passes these checks. However, I am
  uncertain that my submittal succeed. See #1, #2, #3,
  #4 and #5.

R CMD check results
0 errors | 0
  warnings | 0 notes
R CMD check succeeded


  devtools::build_win()
Building windows version of
  cartools for R-devel with
  win-builder.r-project.org.

#1. Warning:
  ‘inst/doc’ files
‘cartools.Rmd’,
  ‘cartools.html’, ‘cartools.R’
  ignored as
  vignettes have been rebuilt.
  Run R CMD build with
  --no-build-vignettes to prevent rebuilding.
*
  checking for LF line-endings in source and make files
  and shell scripts
* checking for empty or unneeded
  directories
* looking to see if a
  ‘data/datalist’ file should be added
#2.
*
  building ‘cartools_0.1.0.tar.gz’
I don't understand what this file is for. I am uploading:  Basic.tar.gz.

#3
I have instructed the following
  folder to be ignored:  .Rproj.user
It is not ignored
  in GitHub. It contains items that I did not
  create.
This does not seem correct,

#4. I
  receievd a win-builder email stating:
Possibly
  mis-spelled words in DESCRIPTION: cartools
  (3:8)
Unknown, possibly mis-spelled, fields in
  DESCRIPTION: 'Remotes'
The above items are
  false/postives.

I don't understand the following
  statement.
The Title field is just the package name:
  provide a real title.

#5. I am a subscriber but my
  questions to r-packages-devel bounce.





=

Original content of DESCRIPTION file:

Package: Basic
Type: Package
Title: CARTOOLS Package
Version: 0.1.0
Author: person("Paul", "Ossenbruggen", email = "p...@unh.edu", role = 
c("aut", "cre"))
Maintainer: "Paul J. Ossenbruggen" mailto:p...@unh.edu>>
Description: The cartools package is designed for college students studying 
transportation engineering and for transportation professionals and researchers 
interested in understanding the complex relationships associated with freeway 
performance and traffic breakdown. Emphasis is placed on: (1) Traffic noise or 
volatility; (2) Driver behavior and safety; and (3) Stochastic modeling, models 
that explain breakdown and performance.
License: MIT + file LICENSE
Encoding: UTF-8
LazyData: true
Depends: R (>= 2.10)
RoxygenNote: 6.1.0
Remotes: pjossenbruggen/Basic
Imports:
animation,
devtools,
dplyr,
gapminder,
ggplot2,
graphics,
grDevices,
knitr,
rlist,
rmarkdown,
roxygen2,
sde,
shiny,
stats,
tidyverse,
usethis,
utils
Suggests:
VignetteBuilder: knitr









[[alternative HTML version deleted]]

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



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