[Pythonmac-SIG] PackageManager link broken?

[Bob Ippolito]

On Wednesday, Sep 24, 2003, at 13:50 America/New_York, Kevin Ollivier  
wrote:

> On Wednesday, September 24, 2003, at 02:46  AM, Bob Ippolito wrote:
>
>> On Wednesday, Sep 24, 2003, at 05:03 America/New_York, Jack Jansen  
>> wrote:
>>
>>>
>>> On Wednesday, September 24, 2003, at 01:16 AM, Kevin Altis wrote:
>>>
>>>> I just did a fresh install of MacPython-OSX-2.3-1.dmg on a new  
>>>> PowerBook and
>>>> then fired up PackageManager to get readline. I got an error dialog:
>>>>
>>>> """
>>>> Cannot open
>>>> http://www.python.org/packman/version-0.3/darwin-6.8- 
>>>> Power_Macintosh.plist:
>>>> HTTP Error 404: Not Found
>>>>
>>>> See MacPython Package Manager help page.
>>>> """
>>>
>>> It's fixed. And I've also (finally) added a link to Bob's packman  
>>> database
>>> to the package manager help.
>>>
>>> The problem is that the darwin version changes with every MacOSX  
>>> micro-release.
>>> While in principle this could cause incompatibilities in practice it  
>>> never
>>> has (as far as I'm aware), so for a next version of PackMan we should
>>> strip the darwin minor release number. Or maybe first try  
>>> "darwin-6.8"
>>> and if that fails "darwin-6".
>>
>> Well in in my experience, all of the modules compiled on OS X 10.2.x  
>> work on all versions (that I've tried) of OS X 10.2.x and OS X 10.3  
>> betas... it's the other way around that is probably going to cause  
>> issues (10.3 -> 10.2). A definite example where a module built for  
>> 10.2.x wouldn't work on 10.3.x *or* vice versa would be if you were  
>> linking against Perl for some reason, because Perl moved.  I'd  
>> imagine the only time that you're going to run into problems is when  
>> you're linking against unix stuff, because all the Apple libraries  
>> are made to be binary compatible or have versionable frameworks that  
>> are tested for backwards compatibility for when they're not.
>>
>> With XCode, Apple introduced a new way to handle part of this.  They  
>> just give you copies of all the headers libraries and frameworks for  
>> the final version of the previous major versions that you can link  
>> against for backwards compatibility:
>> In /Developer/SDKs/ you have: MacOSX10.1.5.sdk/  MacOSX10.2.6.sdk/   
>> MacOSX10.3.0.sdk/
>> When using this with the MACOSX_DEPLOYMENT_TARGET environment  
>> variable, you should be able to build packages in 10.3.x that will  
>> work for 10.2.x users just fine.
>
> Wow, this is really cool! =) I assume this means we could re-introduce  
> 10.1 support, if we wanted to? ;-)

I'm against it, you're not going to see me compiling packages for 10.1  
or dealing with 10.1 support hassles.  I had enough trouble when I was  
*using* 10.1.

>> In any case, I think something more complicated should happen with  
>> Package Manager.  The binary releases should be able to say what they  
>> expect to be compatible with (by way of the plist).. for example,  
>> most of them would have a rule that says 10.2.6 <= your_version, but  
>> some of them would want a rule that says 10.2.6 <= your_version <  
>> 10.3 (where there is a known incompatibility with 10.3.x or where  
>> additional features are enabled for a separate 10.3.x build, which  
>> would say 10.3 <= your_version).  You'd see which of these build  
>> rules pass and choose the most specific one.
>>
>> I also think that the Python major release is much more important  
>> (2.3 -> 2.4) than the operating system release and that a single  
>> binary release shouldn't ever to claim to work with both (unless it's  
>> pure python).  In Win32, for example, I've never seen separate binary  
>> installers for WinXP and Win2K, or whatever, but you always see  
>> separate ones for different versions of Python due to binary  
>> incompatibility.
>>
>> Other things I think that need to be addressed sometime soon are a  
>> standard for *installed* package metadata (this would be  
>> distutils-sig material, I guess, but a LOT of python library authors  
>> will have to be made aware of a new standard).  Maybe you could just  
>> drop PKG-INFO files somewhere in site-packages.
>
> Isn't the standard that PKG-INFO is distributed in the root directory  
> of the site-packages module? (i.e. site-packages/wxPython/PKG-INFO) We  
> would simply need to read this file then.

Doesn't look consistent, I only have one:
/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3
[crack:2.3/lib/python2.3] bob% find . -name "PKG-INFO"
./site-packages/PythonCardPrototype/PKG-INFO

and I have wxPython installed (from their installer).

>> There should to be a standard way to install "extra" stuff.. like  
>> HTML documentation, example applications, etc.  This may also be a  
>> distutils-sig thing.  I don't build "extras" packages yet because I'm  
>> lazy and it would take way more than twice as much work per module  
>> than I'm already doing.
>
> I agree this should be in the package format. In the UI, we can do  
> something similar to the 'component selection' feature in Windows  
> installers. A series of checkboxes will appear, one for each  
> component. Click on the one you want to install; all are installed by  
> default. The question is - where should the extra stuff go? If we  
> define a standard location, they can be "opened" from PackageManager  
> and keep people from having to find site-packages on their hard drive.


How about:
$HOME/Library/Python/$VERSION/doc
/Library/Frameworks/Python.framework/Versions/$VERSION/share/doc

The second one already exists for me, and it seems that IPython and  
pycurl have put documentation and examples in there.

It would be nice if PackageManager could point you to these files.

>> Putting arbitrary code in the plists should probably be replaced with  
>> a more restricted way of doing things.
>>
>> binary / source releases should be consolidated into the same part of  
>> the plist since they' share so much other metadata (name,  
>> description, etc).
>>
>> The UI for Package Manager needs to be cleaned up or replaced.. it  
>> should definitely be a well-behaved OS X application that shows  
>> progress for both download, compilation, and installation.  The  
>> easiest way to do this would probably be to do that kind of work in a  
>> separate process altogether.  I don't really know if wxPython is  
>> really the way to go because of its large dependencies, but PyObjC is  
>> pretty lightweight (could include a special renamed version in the  
>> application bundle, or something, so it would trump anything the user  
>> has installed, but only for the PackageManager UI).
>
> Well, wxPython is the way to go if we want a Windows/Linux version,  
> and this is one tool that IMHO should not be available only to Mac  
> users. Having two UIs means maintaining two separate apps that do the  
> same thing, which may be feasible, but I think consistency is very  
> important to good apps and having different versions on different  
> platforms throws consistency out the window. The large dependencies  
> start becoming less of an issue when we start developing and including  
> high-quality tools that use wxPython within the package. I would like  
> to see Python in general start to look more polished and have the kind  
> of IDE/interface that developers expect of other languages, and if we  
> write it all in PyObjC a majority of Python users will be left out,  
> which I think will be far more detrimental than adding a few MB to the  
> installer package.
>
> IMHO, those who want to use Python just to create a few command-line  
> scripts won't even need PythonMac anyways, especially with Panther, so  
> I think the purpose of PythonMac is to be chock-full of goodies that  
> help developers work with Python, not excluding either cross-platform  
> or Mac-specific development. Anyways, just my 0.02  
> cents/euros/whatever. =)
>
> BTW, has anyone taken played with the wxPackageManager prototype I  
> posted? =)

If the model is entirely in platform independent modules, is there  
something wrong with having a few flavors of UI on top?  Is it really  
so hard to maintain a PyObjC Package Manager (that acts like Mac users  
want it to act), a Win32 Package Manager (that acts like Win32 users  
want it to act), and a generic X11 Package Manager (that acts.. in some  
way).. A curses Package Manager would also be great (a la dselect), on  
top of, of course, a command line utility for querying/installing  
packages.  I think there's too much impedance mismatch on how Mac,  
Win32, X11, and ssh users like their applications to work to use the  
same UI for all three.  Especially for the ssh users :)  Maybe Win32  
and X11 users would be happy with using the same Tkinter or wxPython  
GUI, but I think that Mac users tend to much prefer UIs designed for  
the Mac.

I enjoy PyObjC development and wouldn't mind writing a PyObjC  
equivalent to Package Manager.. it wouldn't be very big or hard to  
maintain, and it would have the added benefit of being intuitive for a  
user of other Cocoa applications.  Another thing is that a PyObjC  
application of about the same complexity as wxPackageManager takes  
about 3 seconds to start (bounces right up until the UI shows) where  
wxPackageManager takes about 10 seconds to start (bounces twice, then  
just sits there with no UI for 8 or 9 seconds).  wxPackageManager also  
does not respond to cmd-Q, but I'm sure that's fixable?

-bob