This is a little irritating. I was trying to write a PyROOT application, and I was trying to give some handy instructions when someone wrote ./MyPyROOTApp --help. But to my dismay, whatever I did:
[code]Usage: python [-l] [-b] [-n] [-q] [dir] [[file:]data.root] [file1.C … fileN.C]
Options:
-b : run in batch mode without graphics
-n : do not execute logon and logoff macros as specified in .rootrc
-q : exit after processing command line macro files
-l : do not show splash screen
dir : if dir is a valid directory cd to it before executing
I thought “that’s odd - python doesn’t have a graphics mode”. I soon realised that this is actually ROOT’s help, not pythons. It is happening as a byproduct of the TApplication instantiation buried within PyROOT.
c = libPyROOT.MakeRootClass( ‘PyROOT::TPyROOTApplication’ )
if c.CreatePyROOTApplication():
c.InitROOTGlobals()
c.InitCINTMessageCallback()
c.InitROOTMessageCallback()
sys.argv = argv
del argv[/code]
Thankfully, the TApplication gets its argv from python rather than directly from the command line (I guess there is almost no other way), but still. This is a really ugly hack, does anyone know a better way?
Yes, sys.argv is picked up by TPyROOTApplication (except when it doesn’t exist, e.g. in Apache).
I’m not quite sure why the workaround needs to be so complicated. Normally, I’d presume a usage of module getopt would be the first thing (so that response to myapp --help or myapp --version would be fast, and not hampered by e.g. loading ROOT), to parse and use the parameters for your own application’s purposes. After that, you can zap sys.argv if it should not be propagated, and only then do ‘import ROOT’?
Well, I might still want to see sys.argv at some point later in the program. This was the most general solution I could find, where I just put a bit of code right at the beginning of any scripts (Actually an initialise script which gets imported by all of my scripts). This is the only way I can find which fixes the problem in this way (and allows me to use sys.argv later).
Also, by convention I like bunching my imports at the top of my scripts, so it would look somehow ugly to me to ‘import getopt … parse getopt code … import ROOT’. I would much prefer to ‘import Initialse … import ROOT … parse options later’.
the options need to be delivered somehow (see the TApplication constructor) … An alternative might be to hand them to CreatePyROOTApplication(), but that would still require extra coding. What about doing the same as you did, but instead of the direct calls on libPyROOT use:import ROOT
ROOT.kTRUE
The latter statement will cause __finalSetup() to be called.