[Distutils] The $0.02 of a packager ;-)

[Greg Ward]

Quoth Oliver Andrich, on 04 February 1999:
> Hm... I am not quite sure what position I should take here. The position of
> the developer or the packager. But let's discuss this. ;-))

There are lots of people developing Python modules, but not too many
packaging them up -- so your opinions as a packager as especially
valuable!  (So I can't understand why you-as-developer advocate pushing
work onto the packager.  >grin<)

> What does actually happen when the packager builds the distribution, let's
> take PIL as an example. The packager (me) calls
> 
> setup.py bdist --rpm
> 
> and these what goes wrong and tweacks such things as wrong include paths,
> wrong library names, evil compilation command switches and so on. Afterwards
> building the distribution might look like that.
> 
> setup.py build --include-path="/usr/include/mypath /usr/local/include/tk/" \
>                --libraries="tcl tclX mytk" \
>                --cflags="$RPM_OPT_FLAGS -mpentiumpro"
> setup.py install --install-dir="/tmp/pyroot/usr"
> setup.py bdist --install-dir="/tmp/pyroot/usr" --rpm
> 
> And this contradicts the actual rpm bnuilding process, cause rpm
> what's to bne able to build the package itself.

[...Greg gets a sinking feeling...]

Urp, you're quite right.  This business of building RPMs is a bit
hairier than I thought.  Here's a *possible* solution to this problem:
have setup.py (well, the Distutils modules really) read/write an options
file that reflects the state of all options for all commands.  (Credit
for this idea goes to Martijn Faassen -- though I don't think Martijn
said the Distutils should also *write* the options file to reflect
user-supplied command-line options.)

The options file would basically be a repository for command-line
options: you could set it up before you run setup.py, and when you run
setup.py with options, they get stuffed in the options file.  Then, the
"bdist --rpm" code uses the options file to create the spec file.

This raises the danger of "yet another Makefile-that's-not-a-Makefile to
edit" though.  Yuck.  Maybe we could call it "Setup" so existing Python
hackers think they know what it is.  ;-)

However, you raise a lot of difficult issues regarding creating RPMs.  I
*still* think we should be able to handle this, but it's looking harder
and harder -- and getting pushed farther and farther onto the
back-burner.  And this is only one of the "smart packagers" out there;
we definitely need some expertise with Solaris 'pkg', the various Mac
and Windows solutions, etc.

I'll leave it at that for now: I'm not going to respond in depth to all
of your concerns, because for the most part I don't have answers.  I
will spend some head-scratching time on them, though.

Oh: implementing a "bdist" command to create "dumb" built distributions
(eg. a tar.gz or zip file) should still be pretty easy, though -- just
tar/zip up the blib directory (minus documentation: hard to say where
that should be installed, since there's no standard for module
documentation).  So *that* doesn't have to be punted on.

> What I like to see is
> 
> setup meta --name
>            --version
>            --short-description
>            --description

Sounds about right to me -- we haven't really discussed what meta-data
is necessary, but this is a bare minimum.  It should be at least a
superset of what RPM knows, though.

> This is fine to hear. Is it also planned that I can check for a certain
> version of library or so? Let's say I need libtk.so.8.1.0 and not
> libtk.so.8.0.0 or is this kept anywhere else? How do you like to implement
> this tests?

No, that's not in the plan and it's a known weakness.  Checking
dependencies on Python itself and other Python modules should be doable, 
so that's what I think should be done.  Open the door beyond that and
you fall into a very deep rat-hole indeed -- a rat-hole that RPM takes
care of quite nicely, and you argued very cogently that we should *not*
duplicate what RPM (and others) already do!

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