[Distutils] Questions about distutils strategy

[Greg Ward]

On 08 December 1999, Tim Peters said:
> The difference between Debug and Release is entirely in switches passed to
> the compiler and linker; makefiles can handle that fine based on target name
> (or envars, or anything else a makefile can see; have DevStudio generate a
> makefile to see how MS does it).  As I hope will become clearer soon,
> though, I don't grasp why any of this is a Distutils issue.

It could be a minor Distutils issue: I've toyed with the idea of
"--debug" or "--optimize" flags (or maybe "--release"?) to the
'build_ext' command that would translate to appropriate compiler
switches.  I know how to do this for the "generic Unix C compiler"
implemented by the UnixCCompiler class, but someone else would have to
do it it for MSVCCompiler.  

> 1) The audience is purely Windows developers.  Then I ship a zip file
> containing source and an MS project file, and leave Distutils out of it
> entirely.

Probably appropriate, although in my more megalomaniacal moments I tend
to think, "Who needs make?  Who needs IDEs?  You can do it ALL with
Python, a C compiler, and Distutils!"  (In an idle moment the other day,
I started thinking about a Distutils command to build Perl
extensions... I got over it pretty quickly though.)

> 2) The audience is purely Windows end users.  Then I ship pre-compiled
> binaries, because they can't possibly deal with compilation themselves (they
> don't have compilers!).  In this case I'm not sure whether Distutils can
> help (it would have to become an Installshield clone to meet expectations);
> but, ragardless, compilation is again not an issue for distribution.

Creating binary distributions is in the plans, although they'll be
called "built distributions" because an RPM that contains only .py (and
maybe .pyc) files isn't really "binary".  The plan decided on at that
fateful Developer's Day session *over a year ago* (wow!) was that we'd
figure out something for Windows with WISE Installer (or whatever it's
called).  I think the theory was that somehow we could write Python code
that would magically generate a Windows installer.  I certainly haven't
done anything about that, although at some point I expect I'll have to
walk downstairs and grill Guido about Windows installers for Python
until he gives up and tells me to bug someone else.

FWIW, the interface I envision is *something* like this:

  $ ./setup.py bdist --format=rpm
  [...create a spec file, run rpm -B...]

  $ ./setup.py bdist --format=wise
  error: can't create Windows installer under Unix

Oops!  Let's try that second one again

  C:\> ./setup.py bdist --format=wise
  [...somehow magically create a WISE installer...]

Hmmm, this is starting to look like yet another argument for system-wide
and user-specific config files to supply default values for things like
the bdist format.  (And, for that matter, the dist format, which can be
one of 'gztar', 'ztar', 'tar', or 'zip'.)

> 4) The audience is Python end-users "in general", and the product is pure
> Python.  I think this is the most important one for Distutils to address,
> and compilation isn't a part of it.  So far, though, what Gordon is doing
> seems more appropriate than what Distutils has been up to.  I hope his work
> gets folded into this.

Here the distinction between "source distributions" and "build
distributions" gets fuzzy.  I actually think it's important and
worthwhile to provide "built" distributions of pure Python distributions
-- not for technical reasons, but for social/political/usability
reasons.  Eg. if I can install a mixed C/Python distribution from an RPM
or a WISE installer, then I should be able to do the same for a pure
Python distribution.  You and I will know that it's a waste of disk
space to offer both versions, and a waste of machine time to have
dist-bots churning out pure Python built distributions from source
distributions, but it's necessary for a consistent user interface on
each platform supported by the "bdist" command.

I assume that "what Gordon is doing" is the Python archive stuff?  My
attitude towards that is the same as it is towards all of these funky
new things coming down the pike: interesting, keep an eye on it, maybe
try it out if I get a few minutes... *but* Distutils support will have
to wait until there is One Standard Way of doing things.  The whole
point of Distutils is to be the One Standard Way; I certainly don't
claim that copying .py files into directories and compiling them to .pyc
files is the only way to install Python module distributions, but until
these issues (archive format, imputils, etc.) are worked out and
finalized then Distutils won't (officially) support them.

Of course, I think it would be really cool if competing archive formats
were presented to the world with implementations in the form of
Distutils command classes, but that's probably my megalomaniacal
tendencies coming out again.

> 5) The audience is Python end-users "in general", and the product is some
> mix of Python and C extension modules.  This is hard.  You have to ship
> binaries to meet Windows expectations; you have to ship source to meet
> Unixish ones; and the more popular Linux gets, the more the Unix dweebs will
> be left whining without a clue about the changing nature of their customer
> base <0.7 wink -- but over on Python-Help the sight of a Linux user who
> doesn't know how to compile is no longer rare>.

As Guido said on python-dev, a Distutils "appdist" command is probably
the answer.  Or maybe "appbdist", I dunno.  I'm not sure if separate
commands are really needed, or if the "build", "install", "dist", and
"bdist" commands will grow up to recognize Python applications rather
than just module distributions.  That's a bit of a ways off, though: I
said at the beginning that I want to handle module distributions first,
and then worry about applications.  Maybe by that time, the "Python
archive format", imputils, one-file-Python-distributions, etc. will be
more stable.

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913