Setting group and owner on installed files
Hello, my Distutils friends! :-) I've been reading this list for a good while, but this is my first message here, so far that I remember. Before going any further, let me express my satisfaction about `distutils', which gives us the mean of very simple and surprisingly quick installations of our Python things. Despite we use some recent Python version on a few machines, we use Python 1.5.2 for most of them. I installed Distutils explicitely on all those, so it is available everywhere and to everybody in the team, here. We are many people (accounts) installing local Python code, and we like avoiding being root while installing. Our setup use 2775 on installation directories and 664 or 775 for installed files, everything under the same Unix group. It would be very convenient to us if we could manage with Distutils, so these permissions and common group were enforced on installation files, directly at `python setup.py install' time. The main purpose of this letter is suggesting such a feature for some later version of Distutils. But also, to welcome any clever suggestion someone could have in the meantime! Keep happy, all! -- François Pinard http://www.iro.umontreal.ca/~pinard
François Pinard wrote:
Hello, my Distutils friends! :-)
I've been reading this list for a good while, but this is my first message here, so far that I remember. Before going any further, let me express my satisfaction about `distutils', which gives us the mean of very simple and surprisingly quick installations of our Python things.
Despite we use some recent Python version on a few machines, we use Python 1.5.2 for most of them. I installed Distutils explicitely on all those, so it is available everywhere and to everybody in the team, here. We are many people (accounts) installing local Python code, and we like avoiding being root while installing. Our setup use 2775 on installation directories and 664 or 775 for installed files, everything under the same Unix group.
Well, the low-level machinery certainly is there in distutils; it's just that the commands don't support setting the installation mode for directories and files. Would make a nice addition indeed. The right location for such a site-wide distutils configuration would be a site setup.cfg file (don't remember where distutils looks for this, but the code should have that information). In the meantime, I'd suggest to use the Unix umask setting and perhaps a small shell script which you tell people to use for installing using distutils (or perhaps create a custom distutils installation which uses your mode settings).
It would be very convenient to us if we could manage with Distutils, so these permissions and common group were enforced on installation files, directly at `python setup.py install' time. The main purpose of this letter is suggesting such a feature for some later version of Distutils. But also, to welcome any clever suggestion someone could have in the meantime!
Patches are always welcome too ;-) -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
[M.-A. Lemburg]
We are many people (accounts) installing local Python code, and we like avoiding being root while installing. Our setup use 2775 on installation directories and 664 or 775 for installed files, everything under the same Unix group.
[...] Would make a nice addition indeed. [...] Patches are always welcome too ;-)
Oh, no doubt that they would be welcome, and quite probable I would have produced some if it was easy for me. You will agree with me that there is a notable distance, between making a suggestion as a mere user, and having understood enough from the code structure and writing philosophy to produce a sensible patch. Until I find enough time for becoming acquainted with distutils internals, best is probably that I try to be a good user first, by at least describing the problems I see, and communicating simple suggestions that come to mind! Even this requires some commitment, you know! :-)
The right location for such a site-wide distutils configuration would be a site setup.cfg file (don't remember where distutils looks for this, but the code should have that information).
Yes, of course, this is exactly what I had in mind. The correct location seems to be: sys.prixe + '/lib/python' + sys.version[:3] + '/distutils/distutils.cfg' but the documentation speaks of `pydistutils' instead of `distutils'. By the way, could this be brought to the attention of the people taking care of this documentation? (I do not have the documentation here, nor easy Web access, and being out of town, I cannot give a precise reference right now -- I hope that a simple editor search through the documentation source will allow to pinpoint the text to adjust.)
In the meantime, I'd suggest to use the Unix umask setting and perhaps a small shell script which you tell people to use for installing using distutils (or perhaps create a custom distutils installation which uses your mode settings).
What I'm doing right now is wrapping the various calls to `setup.py' into a Makefile, as a way to help my co-workers at making the transition, but also to compensate for a few little things like the one above. For example, I use that Makefile to `rm -rf build' before `setup.py build', as I noticed that moved or renamed files will continue getting installed both in their previous and current location or name, which is sometimes inconvenient. Oh, I tried `python setup.py clean', but in simple packages, this yields: running clean warning: clean: 'build/temp.linux-i686-2.0' does not exist -- can't clean it and the `warning:' is not clean enough itself - it raises unneeded questions. By the way, as a general rule everywhere, the word `warning:' should be better written `WARNING:', that little bit of shouting attracts the eye within all the remaining verbosity. I presume that you are like me, and after the few first times around, you do not always read everything, each and every time you build. Warning should stand out, and should not be abused for things not really worth saying. Let me take the opportunity of this message for another little glitch I saw while using `python setup.py sdist'. Whenever a file included from MANIFEST.in happens to be a symbolic link, the generated archive should contain a copy of the pointed to file, and not a mere symbolic link. A symbolic link might have some meaning if the link points elsewhere in the archive, but is not practical if it points to a file which itself not included. The simplest is probably to just never allow symbolic links in generated archives. The `h' option of `tar' should take care of this, but I'm not sure how portable it is to various non-GNU tars. Simpler and safer might be to drive the copy from Python, while preparing the distribution, instead of hard-linking, whenever the original file is a symbolic link. I hope it all sounds reasonable... -- François Pinard http://www.iro.umontreal.ca/~pinard
participants (2)
-
François Pinard
-
M.-A. Lemburg