# SetSystemOptions in a package

I'm looking to update a large package (with subpackage files called in the same context) to be compatible with version 10. A lot of the functionality surrounds plotting, particularly some custom variants of DateListPlot. To get my desired PlotRanges, ticks and date label formats, the package does a lot of manipulation of dates, so it hits the change in the treatment of DateDifference discussed here.

I wanted to just use the following in the preamble of the package, i.e. between the BeginPackage statement and Begin["Private"].

If[$VersionNumber >= 10, SetSystemOptions["DataOptions" -> {"ReturnQuantities" -> False, "ReturnEntities" -> False}] ];  However this does not actually set the system options. Loading the package and then evaluating SystemOptions["DataOptions"]  Returns: {"DataOptions" -> {"ReturnEntities" -> True, "ReturnQuantities" -> True, "UseDataWrappers" -> True}}  The alternative to this would be to add a lot of If[$VersionNumber...] hackery for multiple functions inside the package (and handle DateObject input for each of my custom plot functions, sigh).

So is there any way to set SystemOptions when a package is loaded?

• Seems to work for me. Can you probably add a minimal package code like this one so that we can try what doesn't work for you? Additionally, on what system are you? (Btw, is my edit of your question correct?) – halirutan Mar 17 '15 at 3:41
• Thanks @halirutan - yes, that's the correct edit. Was in a hurry and had forgotten how to do it right. Anyway, the wrinkle I hadn't mentioned is that the packages are in Eclipse Juno, and I'm launching version 10 from there. I don't have write access to the production version of the packages because our IT dept locks access to that folder. (I'm on Windows 7 here.) – Verbeia Mar 17 '15 at 4:14
• @Verbeia Ask your IT dept to fix this. They should know how to fix this if they lock things. And if they do not (what would be really strange), you could ask them to put SetSystemOptions into Kernel/init.m, which might or might not work (you might have to ask Wolfram if it does not, and why they do not have a FrontEnd/init.m per package ...) – Rolf Mertig Mar 17 '15 at 7:41
• I don't think it is a very good idea if a package globally changes system options on load -- after all it might make all other code that would run in that instance and uses the DataFunctions break. Also your code will break if someone resets the system options to their defaults.... – Albert Retey Mar 17 '15 at 11:04

A bit long for a comment but here goes. I will suggest using a wrapper function that "adapts" other functions to the version-10-vs-earlier environments. Something like this maybe.

SetAttributes[version10PlusHandler, HoldAll];

version10PlusHandler[func_] := If[\$VersionNumber < 10,
func
,(*else*)
Module[{opts},
InternalWithLocalSettings[
opts = "DataOptions" /. SystemOptions[];
SetSystemOptions[
"DataOptions" -> {"ReturnQuantities" -> False,
"ReturnEntities" -> False}]
,
func
,
SetSystemOptions["DataOptions" -> opts]
]]]


Now wrap this around function calls that might care about that "DataOptions" setting.

I have not tested this so be prepared to modify as needed, fix typos, whatever.

• I think one might want to use CheckAbort to reset SystemOptions if the user aborts. (I don't write packages for others, so there may other ways to protect the user environment that I don't know about.) – Michael E2 Mar 17 '15 at 21:31
• CheckAbort shouldn't be needed, provided InternalWithLocalSettings behaves as it is supposed to behave (not that it's documented or anything). Actually there has been discussion of someday making it a System context function, with proper documentation. – Daniel Lichtblau Mar 17 '15 at 22:14
• @DanielLichtblau Hi, does WithLocalSettings do anything special except of returning the second argument after evaluation of the third? – Kuba Sep 7 '16 at 5:49
• @Kuba In principle it guarantees that the first and third arguments get evaluated without allowing for jumps outside the "control structures" representing those arguments. In actual practice, I'll just say this is undergoing some amount of work and I'm not sure what will be the eventual result. Hoping to know more in a few weeks, once we've had more time to see how it stands up in testing. – Daniel Lichtblau Sep 7 '16 at 15:07
• @DanielLichtblau ok, thanks, sounds reasonable :) – Kuba Sep 7 '16 at 17:49

I'm a bit embarassed that the answer was so simple. I mentioned that I had the commands

in the preamble of the package, i.e. between the BeginPackage statement and Begin["Private"].

What I needed to do was put it in the init.m file instead. Now it works.