[Pythonmac-SIG] Additional binary packages for Python2.3rc1 on 10.2.6

[Bob Ippolito]

On Monday, Jul 28, 2003, at 17:26 America/New_York, Jack Jansen wrote:

> Bob,
> do you feel like becoming co-scapegoat, so the two of us together 
> become responsible for the contents of the standard PackMan database?
>
> I have a couple of reasons for asking this. The least important one is 
> that anything that gets work out of my hands into someone else's is 
> welcome. The more important one (really!) is that the "supplier side" 
> of PackMan needs work, as you are already experiencing, and I could 
> use help with the design. The plan is that I'll do a PEP on PackMan 
> after 2.3 is out, and initially I thought I could punt on the supplier 
> side of things, but I've already noticed that even for a one-man 
> scapegoat it would be good to have some organisation of things so you 
> don't spend hours frantically searching the net when a new version of 
> Python (or one of the packages used) comes out.
>
> Interested?

Sure, I'll help out.. I have to compile/acquire these packages for 
myself anyways, I may as well spend the extra time to help the rest of 
MacPython out :)

I have some ideas for the direction I think PackageManager should go, 
especially wrt security/authority.. but I have to think about those a 
lot more before I can write them down.  For example, the version of 
Python these things are for should be encoded in the URL, and as we've 
all noticed distutils.util.get_platform() may not necessarily the way 
the packages should be broken up.. especially with regard to pure 
python libraries that are only dependent on the capabilities of Python 
(i.e. 2.2+, 2.3+, etc).  I imagine on other platforms, 
distutils.util.getplatform() isn't even that useful.  As an example, 
Linux is pretty much always going to spit out linux-i686 regardless of 
what version of glibc or whatever it was built with.  I also don't 
recall seeing any categorization metadata in the plist?

>
> Oh, and I'll go through some of your message now anyway:
>
>
> On donderdag, jul 24, 2003, at 04:13 Europe/Amsterdam, Bob Ippolito 
> wrote:
>
>> I've setup a repository for several packages that I use that aren't 
>> in jack's list yet, or weren't compiled correctly for the non-fink 
>> user.
>>
>> The Package Manager URL is:
>> http://undefined.org/python/pimp/darwin-6.6-Power_Macintosh.plist
>>
>> I couldn't find what jack has been using to build binary packages, so 
>> I wrote one that makes it easy.  It's at:
>> http://undefined.org/python/makepimp.py
>>
>> Usage of makepimp is:
>> 	makepimp.py modulename versionnumber
>>
>> It spits out a plist template of what you'd paste into the package 
>> manager file.
>>
>> If you use it, you'll want to change HTTPBASE and UPLOADCMD up at the 
>> top.
>>
>> modulename must already be installed in your site-packages, I have 
>> not tested userdir installation, but it works for me.
>
> I like makepimp a lot (especially the generation of the xml code!) but 
> there are two issues with it:
> 1. It creates a binary installer from an installed package. What I do, 
> and what I think I prefer, is running "python setup.py bdist_dumb" in 
> the build directory.

The reasons I did it from installed packages are:
	(a) I had no idea how you were doing it, so I guessed
	(b) I'm not familiar with all the features of distutils, since I'm 
currently not a release guy for any real project
	(c) I saw ./Library/Frameworks/...../site-packages/ in your tarballs 
and I was like "ooh, that's easy".  I still haven't read the source for 
PackageManager to see if it even works for ~/Library/Python 
installations.

> 2. It has no way to customize the fields in the XML, which means you 
> have to edit them by hand, which means the version (X+1) of the 
> package means to have to start from scratch again.

We all have mice, right?  ;)  Reading in an existing template dict 
would be nice, and trivial to do.  makepimp was a quick hack, it wasn't 
a tool I was planning to use forever :)  I'll roll these two features 
into makepimp when I find the time.

>> The packages I have up so far are:
>> 	readline 2.3c1
>> 	PIL 1.1.4 (with static libjpeg support, no tkinter support)
>> 	egenix-mx-base 2.0.4
>> 	ctypes 0.6.2
>>
>> I'll be adding more sometime (primarily: bsddb3, pyPgSQL, pygame, 
>> twisted),
>
> Of these I definitely want readline before 2.3 is announced. Could you 
> give me a recipy for building it? That is, assuming you've built it 
> with a static libreadline, which is what I need. PIL also needs to be 
> built with a static libjpeg, indeed, but also with Tkinter. Did you 
> modify the existing PM recipe for building PIL from source, or did you 
> start form scratch?
> If the former, what did you have to do?

readline:  http://undefined.org/python/readline-0.0.1.tgz  (this has 
been around for a few weeks, I posted it to the list.. it actually 
"urllib"'s the tarball from gnu.org and compiles it with the right 
options to make it static)

PIL:  I'm pretty sure I did this by hand.. it does what you want it to 
do if you *only* have libjpeg.a on your library path, which is what I 
arranged for it.  If you download the SDL_image source from 
http://www.libsdl.org/projects/SDL_image/ and extract 
PBProjects.tar.gz(?) you can rake out their statically compiled libjpeg 
(I think I compiled my own, but I compiled SDL_image for Panther 
yesterday and I noticed that all the SDL source packages come with a 
PBProjects.tar.gz file that comes with precompiled static versions of 
all their OS X deps, which was a nice surprise).  I can make a recipe 
that builds with tkinter.

>
>> I don't like the current "you have to go fetch this dependency" way 
>> of doing things, so I'll probably end up writing some python-based 
>> installers for libraries like SDL, Tcl/Tk, BerkeleyDB, PostgreSQL, 
>> etc. that will download the binary from somewhere and install, or at 
>> least open up the .pkg for you.
>
> I definitely want this too, at least for some packages (Tcl/Tk, 
> wxPython). For others (Developer Tools) I think it may be overkill. 
> And maybe we should stop at opening the .pkg, or even at opening the 
> .dmg.

I agree with Developer Tools being overkill.  I'd also particularly 
like the SDL frameworks (pygame dependencies) to fit into this scheme.

-bob