[Pythonmac-SIG] PackageManager link broken?

[Kevin Ollivier]

On Wednesday, September 24, 2003, at 11:23  AM, Bob Ippolito wrote:

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

I didn't think there'd be a big demand for this, but 10.2 support for  
10.3 developers may be a different story, however...

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

What I meant is that I think PKG-INFO is auto-created by distutils and  
thus by default always puts the PKG-INFO (when created) in the same  
folder, but I'll have to check into this again.

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

This sounds fine to me.

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

But this is exactly what wxPython is designed for. It's not just so  
that it works everywhere, but so that it works everywhere in the manner  
that users of that platform would expect. The wxPython version should  
act like Mac users expect it to act on Mac, like Windows users expect  
it to act on Windows, and like X11/GTK/Motif/etc. users expect it to  
act. If wxPython isn't doing this, then there are things about wxPython  
that need fixing, and we'd like to hear about them. =)

As a side note, are there special services/behaviors that are  
specifically Cocoa-only and that would benefit PackageManager? From  
what I've seen (i.e. I looked at making Safari accessible from wxMac)  
it seems as if Cocoa libraries could be made accessible to C++/Carbon,  
quite easily in Safari's case.

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

But that's making an implicit assumption that you need to use PyObjC to  
design a UI "for Mac". wxPackageManager was designed for Mac  
specifically, though I would agree it could be improved (especially  
since it's a prototype - I was trying to get ideas/feedback on it). If  
it is not Mac-like in some manners, please let me know what they are so  
that I can look into getting them fixed. I would like all of my  
interfaces to be as optimized for Mac folks as possible, considering  
that I am one! =)

I agree though that a command line version would be great. =)

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

Part of the issue here is that I believe the current wxPython is  
running against debug versions of the wxWindows libraries, which is  
likely affecting startup time somewhat. I've sent a note to Robin Dunn  
about switching to release versions now that the port has been out a  
while. (They're already moving into the 2.5.x unstable port, which will  
probably use debug libraries.) I don't know how much this will help,  
but I will certainly look into it.

Also, thanks for pointing out the cmd-Q thing, it is fixable but it  
might need to be fixed in wxMac because it requires access to the  
application menu. It still leaves it in the File menu for Classic  
support, but I think this week they're branching for classic and moving  
to Carbon-only development. In any case, I can see about getting this  
into the next release of wxPython. (I'll also double-check that the  
shortcut for the Preferences menu works as well.)

Thanks,

Kevin