[Pythonmac-SIG] PackageManager / Python 2.3.x - 2.4 ideas

[Bob Ippolito]

These are some ideas for future versions of Package Manager and 
friends...

Should remove shell executable dependencies because python does these
	tar
	unzip
	zip
	curl
	(not sure if it uses there or not)
	rm
	mv

Should leverage metadata from PyPI in some way

Should read proxy settings from OS X rather than using environment 
variables.. allow a user override, store this as a preference

Should allow user to override 'scratch area', they might not always 
have space in /tmp .. store this as a preference

We should write a cross-platform "preferences" module for python that:
	Uses the registry in win32 to determine a folders for global/user 
plists, and then uses that :)
	Uses ~/Library/Preferences/plists and /Library/Preferences/plists in 
OS X
	Uses somewhere/plists for global settings on unix and 
~/.dotfolder/plists in UNIX

Not have separate plist files for each distutils.util.get_platform() -- 
this is only semi-useful for binary OS X packages, and not useful at 
all for other operating systems.

Have a cryptographically authenticated way of determining the 
authenticity of 'stuff'.  My search to find a pure python way to do 
this failed miserably, *everyone* is using C sourcecode for this.  So 
my proposal for this would be to have two options (1) execute the 
openssl utility if available (2) use pyOpenSSL to do it.  With CPAN for 
example, if you don't have a perl module to do something, it will use 
whatever shell utility it can find to do the task until you actually 
install the module that CPAN is looking for.  I'm doing some research 
to figure out what would be a good way to actually execute this.  I'm 
thinking that Python becomes a central CA, and package repository 
maintainers get certificates from the Python CA.  Perhaps it may also 
be possible to have a package repository maintainer authorize an 
individual package maintainer to manage their package (perform releases 
directly without bothering the package repository maintainer), perhaps 
these could live in an "experimental" repository, and then upon 
approval from a package repository maintainer goes into the "official" 
repository.  OpenSSL also guarantees that we don't really have to worry 
about how secure the implementation is so long as the application is 
otherwise securely designed.  Allow users to trust additional CAs, 
store those as a preference.

The current infrastructure that uses PackageManager is susceptible to 
all kinds of attacks (any sort of 'man in the middle' attack: dns 
spoofing, server hacking, etc).

Keep receipts for installed packages, even if we don't write an 
uninstaller.

Keep track of dependency versions.. for example, FooBar 2.0 might 
require a minimum BarBaz of 1.0 and is tested compatible up to BarBaz 
1.5.  BarBaz might release a wonderful 1.6 version that breaks some 
behavior that FooBar 2.0 or whatever other packages depended on.  
Upgrading to BarBaz 1.6 should warn the user that "FooBar 2.0 and 
SuperAlice 1.5 are dependent on BarBaz 1.0-1.5, but are not tested to 
work with BarBaz 1.6.  This upgrade may require upgrades to these 
dependencies".  Dependency graphs are a lot of fun, but we're all good 
programmers here and we can't be lazy all the time.

Package Manager should be able to install distutils-based setup.py 
source distributions that a user has on his harddrive or at any 
arbitrary URL (i.e. not in the plist) either by dragging the tgz/zip to 
PackageManager, picking a folder with a setup.py in it, or picking a 
setup.py.

Package Manager should be organized categorically, like PyPI. (i.e. 
they should be heavily integrated).

We should test upgrades to Package Manager :)

All of Package Manager's functionality should really be in platform 
independent "designed" modules (meaning they don't have to support 
other platforms yet, just designed with that intent).

Package Manager should be a responsive application, either by using 
nonblocking methods to speak with spawned processes.  Threading sucks 
in python, let's not try and use it too much.

Speaking more with regard to separating the model and view of Package 
Manager, we should think about making the Package Manager GUI speak 
with Package Manager over sockets.. imagine managing python 
installations for everyone on your LAN (that trusts you by SSH, or 
whatever).

my train of thought was distracted by other emails.. I'm sure I'll be 
posting more to this thread later :)

-bob