[Pythonmac-SIG] PackageManager link broken?

Wed Sep 24 13:50:20 EDT 2003

Hi all,

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? ;-)

> 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.

> 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.

> 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? =)

Thanks,

Kevin