[Pythonmac-SIG] PackageManager and Packages

[Bob Ippolito]

On Friday, Oct 3, 2003, at 17:40 America/New_York, Sarwat Khan wrote:

> I've been trying to follow the Package Manager thread and it just 
> keeps piling up and up :P I want to share some thoughts and a 
> suggestion.

Yeah, it's definitely the fastest moving thread I've ever seen in 
pythonmac-sig!

> First of all, I don't like the idea of having executable code in 
> plists. However I'm not a fan of receipts either. I remember on 
> FreeBSD installing XFree86, installing emacs (which can work fine 
> without X), upgrading XFree86 (possibly by uninstalling and installing 
> again), and then finding out that my emacs was screwed. Since X was 
> optional the libraries were removed out from under emacs, and it was 
> screwed. Just my $.02 there; I'd something smarter.

I don't think this is going to be an issue for us.  The scapegoat's job 
is to make sure that the dependencies listed for each package are 
accurate, and we can warn the user when an upgrade takes place.. for 
example:
"Packages X 2.0 and Y 0.4 have not yet been certified to work with 
package Z 1.1, are you sure that you would like to upgrade Z at this 
time?"

As for executable code in the plist, Jack had a good point about 
pre/post install checks and warnings, as with the OS X installer.  I 
don't expect the need to use this feature, but I suppose we could keep 
it so long as it is not required for operation and adequate warnings 
are given to the user of the PackMan client.

> When it comes to comparing versions, I've given up on using "1.0.1b2" 
> and just started using integers and incrementing them. Apple's agvtool 
> (Apple Generic Versioning) defines two version numbers for a product, 
> the 'version' and the 'marketing version.' The version is a floating 
> point number that is always increasing, like 85.5. The marketing 
> version is a string like 1.0.1 b2 and is what the end-user sees. It's 
> MUCH easier to deal with projects that use solid numbers for versions 
> - 2 dimensional version numbers are much easier to compare than 5 
> dimensional ones :P

That's an excellent idea.  This depends on people using distutils in a 
smarter way though :)

> The other thing is that it'd be a lot easier to uninstall packages if 
> they weren't so messy about being installed. This might require a 
> change to Python and how it handles stuff but honestly that's a good 
> thing. zipimport is a great addition as it lets you specify one easily 
> maintainable directory structure for a package, the only downside is 
> that it has to be hard coded into a path (or a .pth I guess). But 
> that's an example. Perhaps there's more we can do to Python's 
> under-used import hooks to make package management easier to deal 
> with; it's best to make the system better at accommodating the needs 
> of a better Package Manager before we write a better Package Manager 
> (like how it'd be great if distutils supported uninstall).
>
> Why can't an entire Python package be installed as a Mac OS X style 
> bundle?
>
> foobar.pyndle/
>     Contents/
>         MacOS/
>             foobar.dylib
>             <compiled os x binaries>
>         Win32/
>             <compiled win32 binaries>
>             foobar.dll
>         Resources/
>             python2.3/
>                 site-packages/
>                     foobar.py
>
> For now, I think you can hack together a .pth that adds enough entries 
> together to make a bundle work. But this would make package removal 
> much easier, although it doesn't directly solve the issue of 
> dependancies. Perhaps Package Manager can maintain a tree based on 
> meta-info provided with each bundle, and rebuild it if it detects it 
> being out of sync.

I like this proposal but I think it may be too much of a change for it 
to get accepted into distutils.

-bob