[Distutils] First steps with distutils...

[Greg Ward]

On 04 September 2000, M.-A. Lemburg said:
> >   error: can't copy 'pkg': doesn't exist or not a regular file
> > 
> > and immediate termination of the setup script (hey, it's an error, not a
> > warning).  I'll admit that's not as useful as it could be, but as long
> > as there's no traceback it's not a bug!  ;-)
> 
> You're right; it's not an exception, but still something which
> causes distutils to stop ;-)

It is fixable, I was just making sure that you and I were seeing the
same problem -- "that's not a bug, it's a misfeature".  Another thing I
discovered this morning is that if MANIFEST is empty, then you *do* get
an exception -- definitely a bug.  So at least a "! empty" check of the
file list is required before trying to copy files and create the
tarball; might as well throw in a "isfile or warn" check on everything
at the same time.

> Would it hurt much adding a "continue" somewhere to remedy
> this minor "caveat" :-)

Well, it'll print a warning that "foo is not a regular file (skipped)".
Not nice to silently skip things!

> That could have been the cause. While testing this I stumbled
> over another bugglet:
> 
> Executing: %build
> + umask 022
> + cd /data/home/lemburg/projects/tmp/build/bdist.linux2/rpm/BUILD
> + cd mx-Extensions-BASE-1.0.0
> + env 'CFLAGS=-O2 -m486 -fno-strength-reduce' python setup.py build
> Traceback (innermost last):
>   File "setup.py", line 7, in ?
>     from distutils.core import setup, Extension
>   File "/home/lemburg/lib/distutils/core.py", line 146
>     raise
>         ^
> SyntaxError: invalid syntax
> 
> This is due to RPM finding a Python 1.5 version under the
> simple name "python".... distutils doesn't seem to be compatible
> with multiple installed Python versions :-( [I did run the
> setup.py file using Python 2.0].

Yup, there's another thread about this very issue going on at this very
moment.  Everyone who has spoken up (me, AMK, and Harry Gebel) thinks
that it should at least be an option to put the value of sys.executable
in the spec file, instead of hard-coding "python".  I think you've
raised another good argument in favour of making this the default, but
I'm biased -- I do think it should be the default.  ;-)

> I then tried:
> 
> projects/tmp> python2.0 setup.py bdist_rpm --prep-script ./prep-script 
> invalid command name './prep-script'
> 
> Looks like somethings wrong there: I can't seem to pass a script
> filename to the command.

The RPM script options are, ummm, not well-thought-out.  Possibly
unfinished, I'm not sure.  Those are the options I was thinking of when
I said it might have been unwise to attempt to mirror *all* of RPM's
spec file in Distutils options.  My inclination is to delete them,
rather than expose a broken interface.

> OK, after that hack the RPM compile runs through, but it now finishes
> with the following lines (and no apparent reason):
> 
> creating /var/tmp/mx-Extensions-BASE-buildroot/usr/local/lib/python2.0/site-packages/mx/Tools
> creating /var/tmp/mx-Extensions-BASE-buildroot/usr/local/lib/python2.0/site-packages/mx/Tools/mxTools
> copying build/lib.linux2/mx/Tools/mxTools/mxTools.so -> /var/tmp/mx-Extensions-BASE-buildroot/usr/local/lib/python2.0/site-packages/mx/Tools/mxTools
> byte-compiling /var/tmp/mx-Extensions-BASE-buildroot/usr/local/lib/python2.0/site-packages/mx/__init__.py to __init__.pyc
> writing list of installed files to 'INSTALLED_FILES'
> warning: install: modules installed to '/var/tmp/mx-Extensions-BASE-buildroot/usr/local/lib/python2.0/site-packages/', which is not in Python's module search path (sys.path) -- you'll have to change the search path yourself
> + exit 0
> Processing files: mx-Extensions-BASE
> File listed twice: /usr/local/lib/python2.0/site-packages/mx/Tools/mxTools/mxTools.so
> Finding provides...
> Finding requires...
> Provides: mxDateTime.so mxProxy.so mxQueue.so mxStack.so mxTextTools.so mxTools.so
> Requires: ld-linux.so.2 libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1)
> error: command 'rpm' failed with exit status 1

??? I'm confused again.

Try running "bdist_rpm" with the --source-only option, and then see if
you can build from the source RPM directly.  About the only way to debug
these sort of problems is to break the thing down, and a *heck* of a lot
of stuff happens between you typing "setup.py bdist_rpm" and the
finished RPM files being moved into dist/.  (Just listen to your hard
drive go!)

> >   * does /data/home/lemburg/projects/tmp/build/bdist.linux2/rpm/RPMS/i386
> >     exist?
> 
> No.
> 
> >   * if you create it, does the bdist_rpm command then run successfully?
> 
> Yes.

OK, based on that and Andrew's feedback, I'd say we blame RPM 3.0.3.

Bottom line: building RPMs with the Distutils requires RPM 3.0.4 or
better.

        Greg
-- 
Greg Ward                                      gward@python.net
http://starship.python.net/~gward/