To follow up with the solution I adopted in quantmod_0.4-3 (on CRAN as of 2014-12-15): I moved all the necessary Defaults functionality directly to quantmod. This did not include Defaults' ability to modify other package's namespaces, since that was a big reason Jeff requested Defaults be archived. This means that getSymbols.MySQL should function as it did when quantmod depended on Defaults. Also, any packages that depend on quantmod and use the ported Defaults functionality should be able to use quantmod_0.4-3 without losing functionality. Packages that use Defaults' ability to modify other package's namespaces will need to be patched to work without that functionality.
On Wed, Oct 29, 2014 at 7:25 AM, Joshua Ulrich <josh.m.ulrich at gmail.com> wrote:
As many of you know, the Defaults package was removed from CRAN on
2014-10-03 at Jeff's request. This broke a fair bit of functionality
in quantmod, most of which I have addressed in recent commits on
R-Forge.
One issue I have not resolved is how to adapt getSymbols.MySQL to the
new no-Defaults paradigm. I will be taking over as maintainer of
quantmod, so I am soliciting input from getSymbols.MySQL users.
My proposed solution to getSymbols.MySQL is to look for specific
option()s if certain arguments are missing. I think this is the
cleanest and most obvious solution, but am open to alternatives. I
would use the option structure below, with only the three arguments
listed.
options(quantmod.defaults = list(
getSymbols.MySQL = list(
user="josh",
password="secret",
dbname="stocks")
)
)
Should I consider another option structure? Should additional
arguments be supported? Anything else I'm missing?
Thanks,
--
Joshua Ulrich | about.me/joshuaulrich
FOSS Trading | www.fosstrading.com
Joshua Ulrich | about.me/joshuaulrich FOSS Trading | www.fosstrading.com