[Distutils] First steps with distutils...

Greg Ward gward@python.net
Sat Sep 9 12:32:03 2000

On 05 September 2000, Harry Henry Gebel said:
> The contents of the spec file are included in the source RPM, that is why A
> think that using sys.executable should be the option and not the default.

Dammit, I'm still waiting for a light to flash on so I can understand
where you guys are coming from on this.  Please indulge me as I think
out loud...

Assertions (please tell me if I'm misunderstanding something):

  * this isn't really all *that* important, as the build instructions in 
    the .spec file only apply to people building the source RPM -- IOW,
    the build instructions in the .spec file in no way affect the
    majority of people who use the RPM, ie. those who just install the
    "built" RPM

  * in fact, the only person who *must* build the source RPM is
    the person who creates the RPM in the first place (although
    anyone creating binary RPMs for other distributions or other
    architectures would probably start from the source RPM)

I've been thinking hard about this -- hey, my brain is slow this weekend
-- and I think I understand it a little better.

Case 1 (the status quo): put "python setup.py ..." in the build/install/
  clean instructions in the .spec file.  This is bad when the packager,
  P, uses a "non-standard" python (anything other than /usr/bin/python)
  to create an RPM that is intended to go in the non-standard location.
  This is mainly a problem when P immediately creates a built RPM from
  his new source RPM (the usual case, in fact); if a builder, B, turns
  source RPM -> built RPM on a separate system, then using the first
  python in the path -- most likely /usr/bin/python -- might well be the
  right thing to do.

Case 2: put sys.executable + " setup.py ..." in the .spec file.
  This fixes the above problem, but is bad in the case where P
  accidentally uses a non-standard python to create an RPM that
  is supposed to go to the standard python installation (/usr).
  Eg. if I forget that /usr/local/bin/python is first in my path,
  then any source RPMs I create will refer to /usr/local/bin/python
  in the .spec file, and building those source RPMs will either
  fail (on systems that don't have /usr/local/bin/python, probably
  the vast majority of installed Linux boxen out there) or will
  generate an RPM with the "non-standard" destination of /usr/local.

In the latter case -- accidentally using the wrong python -- it would be
best if the Distutil issued a warning.  I don't see an easy way to
detect this, especially if someone is deliberately creating an RPM to
install modules to a non-standard location.  (Eg. Andrew's case of
having python in /www/python/bin/python: he might want to make RPMs of
common modules to install on all the web developers' workstations in

Both situations are subtle errors on the packager's part, and neither
seem to have obvious automatic solutions.  The "fix" is social
engineering: let the packager decide what he wants to do with options to 
the bdist_rpm command, and make sure the rationale for each option is
carefully documented.

The question is: which failure is more obvious and happens closest to
the packager, the one who made the mistake (failed to RTFM, etc.)?  That
one should be the default.  It seems to me that creating a source RPM
(spec file) that immediately fails because of an explicit
/path/to/python is better than one that works, but possibly wrongly,
because of implicitly using the first python on the path.

IOW, "Explicit is better than implicit", even in snippets of shell code
included in a .spec file bundled in a source RPM.

Greg Ward                                      gward@python.net
"I came, I saw, she conquered."
(The original Latin seems to have been garbled.)