bugs in fetchData() when loading data from a package.

[rpruim]

From @rpruim on April 17, 2013 14:39

Currently there is a side effect (I think) that the data set with the original name also shows up in the global environment. See the Good Practice section of the data() documentation.

Also, it appears that the workspace takes precedence over the packages:

> HELP <- 3
> HELP
[1] 3
> hhh <- fetchData("HELP")
Data HELP found in package.
> str(hhh)
 num 3
> data(HELP)
> str(HELP)
'data.frame':   453 obs. of  27 variables:

Copied from original issue: ProjectMOSAIC/mosaic#199

[rpruim]

Can we get fetchData() all cleaned up in time for Idaho?

[rpruim]

From @dtkaplan on June 24, 2013 16:47

I'll be testing a new fetchData() this week. This will include the facilities for registering instructor sites so that names like "NJH/stats121/june24.csv" will be directed to whatever http server has been registered under NJH.

Question: Do you want to put the fetchData() functionality in a new package, say fetch, along with other, similar extensions such as fetchGoogle()?

[rpruim]

Hmm. When we started, you may recall that I had suggested multiple packages (mosaicData, mosaicCalc, mosaicStats, etc.) We abandoned that idea to keep things simple and because it seemed unlikely anyone would mind having the whole thing. One downside is that checking the package now takes quite a while, which slows down small incremental fixes.

It seems to me that if we want to return to the idea of multiple packages, then we should think more carefully about the division. The two main reasons for splitting things would be so that users can selectively choose some but not all of the mosaic functionality and to streamline package management.

For now, I say we put this stuff into the mosaic package. We can pull it out later if we decide to split up the mosaic package. But a fetch package seems like too small a division to me. The existence of fetch* functions won't disturb anyone who doesn't use them. (We have other things that are more disturbing than that.)

[rpruim]

If we are making a new fetchData(), let's fix all that ails it while we're at it. Some ideas:

• dispense with the and use read.file() and a designated order of extensions (.rda, .csv, .txt perhaps)
• make sure fetchData() does not change the global environment (except for the object its returned value may be assigned to)
• clean up all the data sets currently available via fetchData() so that they follow our naming conventions.
• make some decisions about how we want fetchData() to handle data in packages
• have fetchData() only do data (don't source code with it)
• perhaps have a wrapper called fetch() that figures out which of fetchData(), fetchGoogle(), source(), etc. to use.

If we like some of these ideas, we can open separate issues for them. For now, I'll leave them hear as discussion items.

[rpruim]

From @nicholasjhorton on June 24, 2013 19:43

I suspect that we'll need some additional time to hash this out.

Danny, what are you hoping to have in time for the PREP workshop? Are there parts of the interface that we'd want to fix for the next release (which I'm guessing we'll want to get out the door in the next week or so).

Nick

On Jun 24, 2013, at 2:14 PM, Randall Pruim notifications@github.com wrote:

If we are making a new fetchData(), let's fix all that ails it while we're at it. Some ideas:

• dispense with the and use read.file() and a designated order of extensions (.rda, .csv, .txt perhaps)
• make sure fetchData() does not change the global environment (except for the object its returned value may be assigned to)
• clean up all the data sets currently available via fetchData() so that they follow our naming conventions.
• make some decisions about how we want fetchData() to handle data in packages
• have fetchData() only do data (don't source code with it)
• perhaps have a wrapper called fetch() that figures out which of fetchData(), fetchGoogle(), source(), etc. to use.
If we like some of these ideas, we can open separate issues for them. For now, I'll leave them hear as discussion items.

—
Reply to this email directly or view it on GitHub.

Nicholas Horton
Department of Mathematics and Statistics, Smith College
Clark Science Center, Northampton, MA 01063-0001
http://www.math.smith.edu/~nhorton

[rpruim]

Danny,

Have you given any more thought to fetchData()?

[rpruim]

Danny,

Another ping... What is the status of fetchData()? As we approach 1.0, we should either get this finished or remove it.

I'm open to moving these sorts of utilities to a separate package if we like.