[Pythonmac-SIG] PackageManager link broken?

[Bob Ippolito]

On Wednesday, Sep 24, 2003, at 15:17 America/New_York, Kevin Ollivier  
wrote:

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

Yeah, but XCode makes that pretty simple, so this should not be a  
problem.  We just have to make sure that developers on 10.3 who want to  
support 10.2 know how to set it up.

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

Yeah I think it makes the files but it doesn't install them anywhere.

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

There's little visual bugs at the wxMac level, as I'm sure you're well  
aware of.. Those tend to burn the eyes of Mac users.  I know this is  
the goal of wxPython, but it's just not there yet and we're talking  
about an application that should be written and deployed in the near  
future.

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

Basically the deal is that Carbon and Cocoa can do the same things, but  
Carbon is the explicit way of doing everything and Cocoa is the easy  
way of doing everything.. For example, Cocoa apps all know how to use  
Services, it's easy to make a Cocoa app scriptable (via Apple Events),  
etc.  It's possible to do all these things from Carbon, but you will  
not have any fun implementing it.

>> 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'm not saying PyObjC is the only way, but it is by far the most fun to  
develop for and is very quick.  Interface Builder is king.

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

But the difference between 3 and 10 seconds is a WHOLE LOT to blame on  
debug libraries.  What the heck could it possibly be doing during that  
time?  That's a whole lot of cycles to go around!

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

Another good thing about PyObjC is that it's low level enough to fix  
almost anything from Python without having to recompiling a really  
large cross-platform GUI framework ;)

-bob