[Pythonmac-SIG] PackageManager and Packages
Sarwat Khan
sarwat at sarwat.net
Fri Oct 3 17:40:06 EDT 2003
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.
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.
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
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.
{sarwat khan : http://sarwat.net}
More information about the Pythonmac-SIG
mailing list