search

DOI-USGS / loadflex

Models and Tools for Watershed Flux Estimates
http://dx.doi.org/10.1890/ES14-00517.1
Other
14 stars 17 forks source link

thinking about example objects #210

Closed aappling-usgs closed 7 years ago

aappling-usgs commented 7 years ago

I'm trying to prepare the way for more and faster examples and tests throughout the package (#209). Exploring the approach of creating things that live in data: pre-prepared example metadata, example model objects and a pair of fitting/prediction datasets that are smaller than lamprey_nitrate and lamprey_discharge.

This is a partial PR because I'm a little hesitant to commit the objects themselves before experimenting with them and getting some initial feedback from y'all. I'm hoping there's enough here to give you a sense of where I'm headed and how I'm documenting the data, and that you can imagine from here how more tests and examples might benefit from this approach.

So...what do you think? Am I on the right track? Or is this too much static data to store, the wrong model objects to store (for the purpose of demonstrations and tests)? How's the naming scheme? Anything else I should be considering?

aappling-usgs commented 7 years ago

thanks for looking, @lindsaycarr ! i was just hoping for a sanity check at this point, so your review is all i need for now, thanks.

agreed that package size is worth considering. The CRAN guideline is currently ~5MB, though we also know that smaller is more convenient, and most packages are smaller than that (http://thecoatlessprofessor.com/programming/size-and-limitations-of-packages-on-cran/). for size's sake, i've considered pulling lamprey_nitrate and lamprey_discharge out of the package, maybe keeping them on GitHub but excluding them from the built package. and then we'd just have the subsets of those data, eg_fitdat and eg_estdat. but given that we're well under the 5Mb guideline, and not submitting to CRAN soon anyway, seems like that change isn't urgent - maybe i'll wait until there's a clearer need.