[Distutils] First steps with distutils...
Tue Sep 5 03:55:04 2000
Greg Ward wrote:
> 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. ;-)
Hmm, this depends on how the spec file is created.
[Warning: I don't know much about RPM...]
If the contents of the spec are included in the RPM file then
it is probably a bad idea to include sys.executable of the
building Python interpreter. In that case, I'd leave the hard-
coded "python" in there and issue a warning that the
executable found as "python" is not identical to sys.executable.
The reason is simple: you cannot know what Python version
a user uses to rebuild from SRPM.
If the spec is *always* recreated, then I'd opt for the
sys.executable default too, since it is natural that
the Python version running setup.py will also take care
of building the RPM sources.
> > 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.
Fine with me... as long as you do publish a working interface
to pass arbitrary RPM options to "rpm" ;-)
> > 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!)
/home/lemburg> rpm -q --whatprovides ld-linux.so.2 libc.so.6 "libc.so.6(GLIBC_2.0)" "libc.so.6(GLIBC_2.1)"
This looks ok, so it's not the "Requires" part which causes the
> > > * 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
I'll try upgrading to rpm 3.0.4...
Python Pages: http://www.lemburg.com/python/