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