[R-pkg-devel] Warning: replacing previous import ...
Dear list, I'm maintainer of the fpc package and got an email that I need to replace a warning that has come up. The warning is: "Warning: replacing previous import ‘mclust::dmvnorm’ by ‘mvtnorm::dmvnorm’ when loading ‘fpc’" Back story: A few month ago I was contacted by the maintainer of mclust that they now incorporate their own dmvnorm function. As dmvnorm is used in my package, he suggested to replace all dmvnorm by mvtnorm::dmvnorm, which I did. Initially this was accepted without warning by CRAN. I don't really understand what I should do about the warning. Isn't mvtnorm::dmvnorm the way to do this, if I want to go on using mvtnorm's dmvnorm function? All "dmvnorm" occurrences in my package are now mvtnorm::dmvnorm as intended and requested. Both mclust and mvtnorm are imported. The only (probably somewhat stupid) idea I have is to list the import of mvtnorm before mclust in NAMESPACE (currently mclust is imported forst), but this seems silly to me - what if I wanted to use both mvtnorm::dmvnorm and mclust::dmvnorm? Any hint? Thanks, Christian -- Christian Hennig Dipartimento di Scienze Statistiche "Paolo Fortunati", Universita di Bologna, phone +39 05120 98163 christian.hen...@unibo.it currently on leave from UCL; UCL email still works __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Warning: replacing previous import ...
Hi Christian, in your NAMESPACE you import both mvtnorm and mclust completely. The warning should go away if you change this to importFrom(...) with only the methods you actually need, in particular dmvnorm either from mvtnorm or from mclust. Alternatively, you could leave out the imports and always use the fully qualified names. This makes it easy to use both mvtnorm::dmvnorm and mclust::dmvnorm in the same package. cheerio ralf On Fri, Jun 28, 2019 at 1:10 PM Christian Martin Hennig wrote: > > Dear list, > > I'm maintainer of the fpc package and got an email that I need to > replace a warning that has come up. The warning is: > > "Warning: replacing previous import ‘mclust::dmvnorm’ by > ‘mvtnorm::dmvnorm’ when loading ‘fpc’" > > Back story: A few month ago I was contacted by the maintainer of mclust > that they now incorporate their own dmvnorm function. As dmvnorm is used > in my package, he suggested to replace all dmvnorm by mvtnorm::dmvnorm, > which I did. Initially this was accepted without warning by CRAN. > > I don't really understand what I should do about the warning. Isn't > mvtnorm::dmvnorm the way to do this, if I want to go on using mvtnorm's > dmvnorm function? All "dmvnorm" occurrences in my package are now > mvtnorm::dmvnorm as intended and requested. Both mclust and mvtnorm are > imported. The only (probably somewhat stupid) idea I have is to list the > import of mvtnorm before mclust in NAMESPACE (currently mclust is > imported forst), but this seems silly to me - what if I wanted to use > both mvtnorm::dmvnorm and mclust::dmvnorm? > > Any hint? > > Thanks, > > Christian > > -- > Christian Hennig > Dipartimento di Scienze Statistiche "Paolo Fortunati", > Universita di Bologna, phone +39 05120 98163 > christian.hen...@unibo.it > currently on leave from UCL; UCL email still works > > __ > 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] implications of staged install for data processing packages
Hi all I ran into trouble with the changes starting to come in with R3.6 stemming from the new staged installation, which checks and errors on hard coded paths in R code. I understand there is an opt out, but still want to know. here's the blog post: https://developer.r-project.org/Blog/public/2019/02/14/staged-install/ I have several packages which look like that: 1. large messy dataset stored on disk as `filename`, maybe a csv. 2. R package has a function `clean(filename)` which reads the data and brings it into useable form 3. R package does analysis 4. R package exports results `filename` is hard coded. What is the proper way to do this instead? Should I store the inital raw data inside the R package in `/inst`? These things are typically very large, so I like to decouple the raw data from the package (easier to share). thanks for any suggestions! [[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] implications of staged install for data processing packages
You need to give details what exactly gets you into trouble and about your use case, since any advice would be conditional on making assumptions about that. It is usually a bad a idea to have a function working on a hardcoded full filename. You will thank yourself later if you at least make it argument to your function(s). It can have for default value the one that is currently hardcoded. Please note that your use case does not seem inherently related to staged installation. "Hardcoded" in the context of staged installation does not refer to any hardcoded path but to those paths that contain the temporary installation directory. Such paths can be obtained, for example, with calls to system.path(), as illustrated by Tomas. Georgi Boshnakov -Original Message- From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf Of Florian Oswald Sent: 28 June 2019 09:17 To: r-package-devel@r-project.org Subject: [R-pkg-devel] implications of staged install for data processing packages Hi all I ran into trouble with the changes starting to come in with R3.6 stemming from the new staged installation, which checks and errors on hard coded paths in R code. I understand there is an opt out, but still want to know. here's the blog post: https://developer.r-project.org/Blog/public/2019/02/14/staged-install/ I have several packages which look like that: 1. large messy dataset stored on disk as `filename`, maybe a csv. 2. R package has a function `clean(filename)` which reads the data and brings it into useable form 3. R package does analysis 4. R package exports results `filename` is hard coded. What is the proper way to do this instead? Should I store the inital raw data inside the R package in `/inst`? These things are typically very large, so I like to decouple the raw data from the package (easier to share). thanks for any suggestions! [[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] implications of staged install for data processing packages
oh ok i see: so i will always be able to do clean(path = "~/data.csv") for example? in that case I completely misunderstood this and there must indeed be some system.file call buried somewhere. will check. thanks! Florian On Fri, 28 Jun 2019 at 17:11, Georgi Boshnakov < georgi.boshna...@manchester.ac.uk> wrote: > You need to give details what exactly gets you into trouble and about your > use case, since any advice would be conditional on making assumptions about > that. It is usually a bad a idea to have a function working on a hardcoded > full filename. You will thank yourself later if you at least make it > argument to your function(s). It can have for default value the one that is > currently hardcoded. > > Please note that your use case does not seem inherently related to staged > installation. > "Hardcoded" in the context of staged installation does not refer to any > hardcoded path > but to those paths that contain the temporary installation directory. Such > paths can be obtained, > for example, with calls to system.path(), as illustrated by Tomas. > > Georgi Boshnakov > > > > -Original Message- > From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On > Behalf Of Florian Oswald > Sent: 28 June 2019 09:17 > To: r-package-devel@r-project.org > Subject: [R-pkg-devel] implications of staged install for data processing > packages > > Hi all > > I ran into trouble with the changes starting to come in with R3.6 stemming > from the new staged installation, which checks and errors on hard coded > paths in R code. I understand there is an opt out, but still want to know. > here's the blog post: > https://developer.r-project.org/Blog/public/2019/02/14/staged-install/ > > I have several packages which look like that: > >1. large messy dataset stored on disk as `filename`, maybe a csv. >2. R package has a function `clean(filename)` which reads the data and >brings it into useable form >3. R package does analysis >4. R package exports results > > `filename` is hard coded. What is the proper way to do this instead? Should > I store the inital raw data inside the R package in `/inst`? These things > are typically very large, so I like to decouple the raw data from the > package (easier to share). > > thanks for any suggestions! > > [[alternative HTML version deleted]] > > __ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel > [[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] implications of staged install for data processing packages
On 6/28/19 5:16 PM, Florian Oswald wrote: oh ok i see: so i will always be able to do clean(path = "~/data.csv") for example? in that case I completely misunderstood this and there must indeed be some system.file call buried somewhere. will check. thanks! In case it is hard to find manually, there is a script at https://github.com/kalibera/rstagedinst (described also in the blog post about staged install), which finds variables holding hard-coded paths to the temporary installation directory. Please give a reproducible example (e.g. the package, output from the script, output from the installation with the error, etc) if you needed more help. Best Tomas Florian On Fri, 28 Jun 2019 at 17:11, Georgi Boshnakov < georgi.boshna...@manchester.ac.uk> wrote: You need to give details what exactly gets you into trouble and about your use case, since any advice would be conditional on making assumptions about that. It is usually a bad a idea to have a function working on a hardcoded full filename. You will thank yourself later if you at least make it argument to your function(s). It can have for default value the one that is currently hardcoded. Please note that your use case does not seem inherently related to staged installation. "Hardcoded" in the context of staged installation does not refer to any hardcoded path but to those paths that contain the temporary installation directory. Such paths can be obtained, for example, with calls to system.path(), as illustrated by Tomas. Georgi Boshnakov -Original Message- From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On Behalf Of Florian Oswald Sent: 28 June 2019 09:17 To: r-package-devel@r-project.org Subject: [R-pkg-devel] implications of staged install for data processing packages Hi all I ran into trouble with the changes starting to come in with R3.6 stemming from the new staged installation, which checks and errors on hard coded paths in R code. I understand there is an opt out, but still want to know. here's the blog post: https://developer.r-project.org/Blog/public/2019/02/14/staged-install/ I have several packages which look like that: 1. large messy dataset stored on disk as `filename`, maybe a csv. 2. R package has a function `clean(filename)` which reads the data and brings it into useable form 3. R package does analysis 4. R package exports results `filename` is hard coded. What is the proper way to do this instead? Should I store the inital raw data inside the R package in `/inst`? These things are typically very large, so I like to decouple the raw data from the package (easier to share). thanks for any suggestions! [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel [[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] implications of staged install for data processing packages
brilliant! thanks a lot, and yes, will come back with more in case I'm stuck. F On Fri, 28 Jun 2019 at 17:44, Tomas Kalibera wrote: > On 6/28/19 5:16 PM, Florian Oswald wrote: > > oh ok i see: so i will always be able to do > > > > clean(path = "~/data.csv") > > > > for example? in that case I completely misunderstood this and there must > > indeed be some system.file call buried somewhere. will check. thanks! > > In case it is hard to find manually, there is a script at > https://github.com/kalibera/rstagedinst (described also in the blog post > about staged install), which finds variables holding hard-coded paths to > the temporary installation directory. Please give a reproducible example > (e.g. the package, output from the script, output from the installation > with the error, etc) if you needed more help. > > Best > Tomas > > > > > Florian > > > > On Fri, 28 Jun 2019 at 17:11, Georgi Boshnakov < > > georgi.boshna...@manchester.ac.uk> wrote: > > > >> You need to give details what exactly gets you into trouble and about > your > >> use case, since any advice would be conditional on making assumptions > about > >> that. It is usually a bad a idea to have a function working on a > hardcoded > >> full filename. You will thank yourself later if you at least make it > >> argument to your function(s). It can have for default value the one > that is > >> currently hardcoded. > >> > >> Please note that your use case does not seem inherently related to > staged > >> installation. > >> "Hardcoded" in the context of staged installation does not refer to any > >> hardcoded path > >> but to those paths that contain the temporary installation directory. > Such > >> paths can be obtained, > >> for example, with calls to system.path(), as illustrated by Tomas. > >> > >> Georgi Boshnakov > >> > >> > >> > >> -Original Message- > >> From: R-package-devel [mailto:r-package-devel-boun...@r-project.org] On > >> Behalf Of Florian Oswald > >> Sent: 28 June 2019 09:17 > >> To: r-package-devel@r-project.org > >> Subject: [R-pkg-devel] implications of staged install for data > processing > >> packages > >> > >> Hi all > >> > >> I ran into trouble with the changes starting to come in with R3.6 > stemming > >> from the new staged installation, which checks and errors on hard coded > >> paths in R code. I understand there is an opt out, but still want to > know. > >> here's the blog post: > >> https://developer.r-project.org/Blog/public/2019/02/14/staged-install/ > >> > >> I have several packages which look like that: > >> > >> 1. large messy dataset stored on disk as `filename`, maybe a csv. > >> 2. R package has a function `clean(filename)` which reads the data > and > >> brings it into useable form > >> 3. R package does analysis > >> 4. R package exports results > >> > >> `filename` is hard coded. What is the proper way to do this instead? > Should > >> I store the inital raw data inside the R package in `/inst`? These > things > >> are typically very large, so I like to decouple the raw data from the > >> package (easier to share). > >> > >> thanks for any suggestions! > >> > >> [[alternative HTML version deleted]] > >> > >> __ > >> R-package-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > >> > > [[alternative HTML version deleted]] > > > > __ > > R-package-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
