On Fri, Aug 13, 2010 at 03:15:28AM +0200, Éric Araujo wrote: > > A good alternative would be to make the config file overridable. That way > > you can have sysconfig.cfg next to sysconfig.py or in a known config > > directory relative to the python stdlib install but also let the > > distributions and individual sites override the defaults by making changes > > to /etc/python3/sysconfig.cfg for instance. > > Putting configuration files next to source code does not agree with the > FHS. > That depends -- sometimes a config file is actually a data file. In following the FHS, a linux distribtuion and system administrators want to make sure a sysadmin never needs to modify a file outside of /etc for configuration. However, if you had a config file that is installed with python and not meant to be modified next to the code and the sysadmin is able to customize python's behaviour by copying lines from that file to a file in /etc/ that they do modify, that's perfectly fine. Where developers often run afoul of the FHS is creating a configuration option that does not live in a file in /etc/ (either because they think it's data but system administrators routinely want to modify.it or because they don't care about the FHS and just want to put everything in a single directory) and hte system admin has no means to set that option permanently but to modify the files outside of /etc/.
>
> Your message gave me an idea though: Some function could be called
> in sitecustomize (symlinked from /etc on Debian e.g.) to set the path to
> sysconfig.cfg.
>
I hope that you mean that the actual file lives in /etc/ and then a symlink
in the stdlib points to it. That sounds acceptable from an FHS view but
it's a bad idea. Most of the config files in /etc/ are declarative. A few
of the files in /etc/ are imperative (for instance, init scripts) and
distributions frequently debate whether these are actually config files or
files misplaced in /etc/ for historical reasons. Fedora, for instance, does
not mark initscripts as config -- all configuration of initscripts are done
by setting shell variables in a different file which is marked config.
(Files marked config in a package manager generally are treated differently
on upgrades. If the files have been modified since install, they are either
not replaced or, when replaced, a backup is made so that the system
administrator can merge their local changes.)
The problem with having imperative constructs in /etc/ is that they're much
harder (perhaps impossible) to fix up when changes have to be made at the
system packaging level. Let's say that you hard code this into the
sitecustomize.py when you ship it for the first time on Fedora:
siteconfig_cfg = '/etc/siteconfig.cfg'
The system administrator installs this package and then does some unrelated
customization for his site in the file:
if sys.version_info[:2] == '3.0':
sys.path.append('/opt/python3.0')
siteconfig_cfg = '/etc/siteconfig30.cfg'
elif sys.version_info[:2] == '3.1':
sys.path.append(os.environ['USER'] + '/opt/python3.1')
siteconfig_cfg = '/etc/siteconfig31.cfg'
elif sys.version_info[:2] == '3.2':
sys.path.append(os.environ['USER'] + '/opt/python3.2')
siteconfig_cfg = '/etc/siteconfig.cfg'
# [...] Do other strange stuff because if it's possible, someone will.
Now, when we update to python3.3 we decide to move siteconfig.cfg into
/etc/python3.3/. But, because the system admin has modified that file so
heavily, we don't update that file. This means the updated python is broken
out of the box.
If you're enamoured of symlinks, you can do this directly with the config
file instead of using sitecustomize::
/etc/python3.2/sysconfig.cfg
/usr/lib64/python3.2/sysconfig.cfg => /etc/python3.2/sysconfig.cfg
as a third alternative.
-Toshio
pgpCYTDznfbDR.pgp
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
