Add capability for global configuration information about pint HOT 9 OPEN

Rather than start a separate thread, I will just put my comments here. Potential other uses for a config file:

• specific log messages to ignore
• clock file setup (at least until that changes)
• logging level/format (configurable via environment variable)
• any pintk-related settings?

from pint.

This is not directly addressed yet, but some of the framework started in #115 (pint.config module, inclusion of appdirs package) is meant to be extended to handle this type of thing.

from pint.

What if we do the following:

• Have a file in the pint distro that contains defaults for all global configuration settings
• Have pint.config read it in in some way so any PINT function can access it easily
• Have a way to override any subset of the defaults by specifying a user configuration file, e.g. pint.config.load('myconfig.rc')
• And users should be able to override config files programmatically without needing to write a config file (e.g. pint.config.settings['UNITS'] = 'TCB')

If that sounds good, we just have to decide exactly how to implement it.

Questions:

• What file format should the config file be in? YAML or INI or Python?
• Where should the default config file be stored? In the top level pint directory, in a subdir like pint/etc or pint/rc, or in pint/datafiles (which already exists)?
• Should users be able to have a file like ~/.pintrc that holds their own defaults that are automatically read in? Or, should users be able to edit the default configuration in the PINT distro (I vote no on this)? I kind of think always having to load your own changes explicitly is good. You may well have a pulsar.tim, pulsar.par, and pulsar.conf set of files for any particular pulsar you are working on, but that is fine. If it reads a user-based .pintrc file it may be very hard to debug because you could forget what changes you'd made in there.

Notes:

• A very simple way to do this with YAML is shows here: http://btmiller.com/2015/04/11/simple-config-setup-python-yaml.html
• A discussion of various configuration file formats for Python codes is here: https://martin-thoma.com/configuration-files-in-python/

Discuss... @scottransom @cdeil @luojing1211

from pint.

Paul, a few thoughts on this:

I didn't fully implement this yet, but my intention with the Observatory code is that PINT will look for a user-specific observatories.py and allow it to override the default PINT-installed one. This file would reside in the appdirs.user_data_dir(), same as what we've done for other user-specific data files (see pint/config.py for usage). I think a similar approach would be fine for a more general config file, there is a user_config_dir() function also. The appdirs package is meant to provide a platform-independent way of getting config file locations and such.

I think I would prefer to just use python files for configuration.

Finally, I think we should have some more discussion of what exactly we mean by global configuration parameters. In my view, these would be things like (for example) level of verbosity in log/warning messages, or what colors to use in a GUI, etc. I think this is not really the right way to deal with UNITS, or most of the other things listed on the wiki page linked in the original comment above. UNITS is a setting associated with a specific timing model, so even though it's not a "fit parameter", it should somehow be part of the timing model instance, not in a global variable. (A default UNITS setting could be a global param, but that's probably a bad example since it will just perpetuate ongoing TCB/TDB issues.)

from pint.

The reason for this issue is because some parameters in the .par file can not be categorized to our TimingModel module. UNITs or EPHEM technically is a selection of a time model and solar system dynamic model. But for the code point of view, they are not really in the PINT TimingModel category. Instead, they only affect the TOA module. That conflicts our philosophy of modularization.

Imagine, one set up TOAs class first with the default value. Then, reading a .par which has different set up. TOAs class will be computed again. This sounds a little bit annoy to me.

from pint.

@demorest I agree with your suggestion that program configuration parameters that have nothing to do with timing models or TOAs could be in a configuration file in usr_config_dir(). This is quite easy to implement.

The more interesting question is how to handle those tricky cases of parameters traditionally in the par file that affect the TOAs and such. In this sense, 'global', means breaking the modularity between TimingModels (initialized from par files) and TOAs (initialized from .tim files), as @luojing1211 said. We need to figure out how to do this. One way to do this is to have another object that stores configuration information of that type. This could be initialized from a file, or programmatically. If it is globally available (e.g. as pint.PINTConfig or something like that), then both TimingModel and TOA objects could access those values. If the defaults are not correct, then the config info should be read in from a file before reading TOAs or building a TimingModel. For PINT, this should be a new configuration file distinct from the .tim or .par files. But, for backwards compatibility, the init method of PINTConfig should also accept a .par file and it would parse just the config info from it (e.g. UNITS, EPHEM, PLANET_SHAPIRO), so that would be known before reading TOAs or building a model.

How does that sound?

P.S. It has long been my opinion that there should never be a default for UNITS. Every par file should be required to specify UNITS.

from pint.

I actually vote against the configuration file being Python. Say we come up with a good plan for splitting that information out into a separate file and in the future TEMPO or Tempo2 want to support that mode. If it is in Python, it is difficult for them, but if it is in YAML, it is easy. I think information like that should not require knowing the language the code is written in.

from pint.

#748 is providing a solution to this issue, maybe partially.

from pint.

I am quite vary of global configurations. This has to do with my bad experiences with PSRCHIVE configuration (.psrchive.cfg). In my experience, I have faced the following issues related to global configurations.:

1. The same installation of PINT (with identical dependencies) can behave differently for different users in the same machine who are trying to do the same thing (e.g. run the same pipeline).
2. It will be impossible to configure two different installations (e.g. associated with two different conda environments) differently if the config file is something like $HOME/.pintrc.
3. A user who is not aware of the global settings will have a hard time figuring out why the two issues above are happening, since .pintrc will be a hidden file.

So I am all for controlling the behavior of PINT explicitly in code or through command line arguments and against a global config.

from pint.