Hi,
I am working on a proposal that will add the need to have a new .cfg file to read for a stdlib package. This is an existing need already for distutils (with distutils.cfg).
I have a proposal: let's create a mechanism that allows a stdlib package to store values in a central configuration file that can be overriden by a per-user configuration file.
This file would be located in the "data" path returned by the install scheme (see sysconfig.py for details)
so roughly : in sys.prefix for the global one, and in ~/.local/ for the local per-user one.
Then each package would look in the local one and "update" the global one with it if found
The files would be a configparser ini-like file, with one mandatory section that is the name of the package or module in the stdlib the filename
For example, if "multiprocessing" needs a configuration file, it will be called "multiprocessing.cfg" and have at least one section:
[multiprocessing] foo = 1
Last, the configparser (or replacer) would provide a new API called "get_config(package_name)" that would read the configuration and return a config object packages can work with.
A nice add-on would be to make it possible to configure the paths, so os packagers could drive where the cfg file should be located on their systems
Does it sounds like a good idea ?
Regards Tarek
Tarek Ziadé <ziade.tarek@...> writes:
This file would be located in the "data" path returned by the install scheme (see sysconfig.py for details)
so roughly : in sys.prefix for the global one, and in ~/.local/ for the local per-user one.
I think it has already been discussed that it's not really the right place for configuration files. sys.prefix is wrong for that, as well as ~/.local.
If Python needs to have a notion of a standard path for config files, it should be something separate from the "data" path.
The files would be a configparser ini-like file, with one mandatory section that is the name of the package or module in the stdlib the filename
Why such a constraint? Isn't the name of the file sufficient?
Antoine.
On Sat, Feb 6, 2010 at 10:55 PM, Antoine Pitrou solipsis@pitrou.net wrote:
Tarek Ziadé <ziade.tarek@...> writes:
This file would be located in the "data" path returned by the install scheme (see sysconfig.py for details)
so roughly : in sys.prefix for the global one, and in ~/.local/ for the local per-user one.
I think it has already been discussed that it's not really the right place for configuration files. sys.prefix is wrong for that, as well as ~/.local.
I am not discussing the right place for those file (e.g. if a better place exists, this will have to be dealt in sysconfig). I am just giving an example of a local/global place that we would use with Python *today* if this file is considered as a 'data' file.
IOW, we could always add a path in Python install schemes for defining the right place for configuration file, and then use it in the idea I am presenting. (and I think its a good idea)
If Python needs to have a notion of a standard path for config files, it should be something separate from the "data" path.
The files would be a configparser ini-like file, with one mandatory section that is the name of the package or module in the stdlib the filename
Why such a constraint? Isn't the name of the file sufficient?
Sure
Tarek
On Sat, Feb 6, 2010 at 11:55 PM, Tarek Ziadé ziade.tarek@gmail.com wrote: [..]
IOW, we could always add a path in Python install schemes for defining the right place for configuration file, and then use it in the idea I am presenting. (and I think its a good idea)
-> the idea of adding a particular path for configuration files ;)