Re: [Distutils] Where to find config files
Greg Ward wrote: [snip]
On Unix, there are three possible config files: pydistutils.cfg in the Distutils installation directory (ie. where the top-level Distutils __inst__.py file lives), .pydistutils.cfg in the user's home directory, and setup.cfg in the current directory.
[snip] I totally agree with the site-home-currentdir structure, but shouldn't the site level file live someplace apart from the code? If you customize the site file, you probably don't want your changes clobbered by a subsequent distutils install. sys.prefix + '/etc', perhaps? ============================================================================= michaelMuller = mmuller@enduden.com | http://www.cloud9.net/~proteus ----------------------------------------------------------------------------- Mantra for the 60's: Tune in, turn on, drop out Mantra for the 90's: Turn on, jack in, jerk off =============================================================================
On 05 May 2000, Michael Muller said:
I totally agree with the site-home-currentdir structure, but shouldn't the site level file live someplace apart from the code? If you customize the site file, you probably don't want your changes clobbered by a subsequent distutils install. sys.prefix + '/etc', perhaps?
That's the nice thing about how sys.prefix "belongs" to Python on Windows and Mac OS. I'm not super-keen on /usr/local/etc; I'd rather keep the Distutils config file somewhere in the Python library tree. Thus, the distutils (or site-packages/distutils, for pre-1.6) directory makes sense. I'm open to other ideas. Clobbering on subsequent installations can be prevented by not installing a config file; that'll make it a little harder for people to find out that they have the option of customizing via a config file, but that doesn't bother me excessively. (Awww, the poor babies will have to read a manual... *sniff* *sniff*) Anyone else give a hoot? Greg -- Greg Ward - Unix bigot gward@python.net http://starship.python.net/~gward/ Any priest or shaman must be presumed guilty until proven innocent.
Greg Ward writes:
Anyone else give a hoot?
Another possibility is to only install the file if it doesn't already exist, which would be my preference. The $prefix/lib/python1.X/ directory doesn't currently contain much in the way of data files; it can contain .pth files, but those are normally in $prefix/lib/python1.5/site-packages/. That may not be a bad location for it, but I'm not really comfortable with using that for misc. configuration files. Placing it there would also imply that the file is site-specific, which isn't a bad thing in this case. It could be called distutils.conf. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
On Mon, May 08, 2000 at 09:22:09PM -0400, Greg Ward wrote:
On 05 May 2000, Michael Muller said:
I totally agree with the site-home-currentdir structure, but shouldn't the site level file live someplace apart from the code? If you customize the site file, you probably don't want your changes clobbered by a subsequent distutils install. sys.prefix + '/etc', perhaps?
That's the nice thing about how sys.prefix "belongs" to Python on Windows and Mac OS. I'm not super-keen on /usr/local/etc; I'd rather keep the Distutils config file somewhere in the Python library tree. Thus, the distutils (or site-packages/distutils, for pre-1.6) directory makes sense. I'm open to other ideas.
Au contraire for Debian and the like. ;-) Think about installations where Distutils live in a read-only tree (e.g. mounted read-only per NFS), or a tree that's shared across many different systems and platforms. In Debian's case, the directive is to keep *all* system-wide configuration files in /etc. The /usr tree (less /usr/local) should potentially be mountable read-only. Variable data goes into /var. That's also the sketch of the Linux Filesystem Standard (now FHS). Btw, I think as a consequence even site.py should be moved from lib/python1.X to /etc. In the end, I guess this is a philosophical question, and the answer will be different depending on your viewpoint (standalone Windoid/Macoid machines or homo/heterogeneous networked systems potentially sharing a common filespace). Gregor
Gregor Hoffleit writes:
In Debian's case, the directive is to keep *all* system-wide configuration files in /etc. The /usr tree (less /usr/local) should potentially be mountable read-only. Variable data goes into /var. That's also the sketch of the Linux Filesystem Standard (now FHS).
Btw, I think as a consequence even site.py should be moved from lib/python1.X to /etc.
Not site.py, but sitecustomize.py, which is where local modifications should go. This is *not* included in the distribution, so it not an installation problem, but the site-admin would need to create a .pth in the shared area that added some directory to sys.path (say, /etc/python/site-packages) so that individual host-admins could add packages locally. But this begs the question: in such an environment, would it generally make sense to support host-specific additions?
In the end, I guess this is a philosophical question, and the answer will be different depending on your viewpoint (standalone Windoid/Macoid machines or homo/heterogeneous networked systems potentially sharing a common filespace).
And depending on how you think that shared filespace should be managed; we use shared spaces here for all the "extras" (but not the base installations), but we all of us that use that shared space can update it. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
On Tue, May 09, 2000 at 11:15:05AM -0400, Fred L. Drake, Jr. wrote:
Gregor Hoffleit writes:
Btw, I think as a consequence even site.py should be moved from lib/python1.X to /etc.
Not site.py, but sitecustomize.py, which is where local modifications should go. This is *not* included in the distribution, so it not an installation problem, but the site-admin would need to create a .pth in the shared area that added some directory to sys.path (say, /etc/python/site-packages) so that individual host-admins could add packages locally. But this begs the question: in such an environment, would it generally make sense to support host-specific additions?
I think so. Currently the Debian package adds /usr/local/ directories to sys.path in site.py: "FOR DEBIAN, this sys.path is augmented with directories in /usr/local. Local addons go into /usr/local/lib/python<version>/site-packages (resp. /usr/local/lib/site-python), Debian addons install into /usr/lib/python<version>/site-packages." It's a question of Debian policy that things in /usr/local should override things in /usr, therefore I need to add these /usr/local/lib directories in front of their /usr/lib equivalents, e.g.
sys.path ['', '/usr/lib/python1.5/', '/usr/lib/python1.5/plat-linux2', '/usr/lib/python1.5/lib-tk', '/usr/lib/python1.5/lib-dynload', '/usr/local/lib/python1.5/site-packages', '/usr/local/lib/python1.5/site-packages/GMatH', '/usr/local/lib/site-python', '/usr/lib/python1.5/site-packages', '/usr/lib/site-python']
I think this is not possible using .pth files, nor with sitecustomize.py, therefore this was done in site.py. Now I guess I should include a .pth file in the Debian package so that something like /etc/python is appended to sys.path, and then the sysadmin should be educated to use /etc/python/sitecustomize.py to further modify the path. Or does anybody have a better solution here ? Gregor
participants (5)
-
Fred L. Drake, Jr. -
Greg Ward -
Gregor Hoffleit -
Gregor Hoffleit -
Michael Muller