[Distutils] Re: Setting group and owner on installed files

[François Pinard]

[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