[Distutils] Package/Module/Recipe Versioning, Aggregation and Distrobution

[distutils-sig at claytonbrown.net]

I have been developing a bootstrap loader to enable module/package & python interpretor versioning/specification at time of import within a script.
This is primarily to encourage code re-use/portablility (satisfying dependancies on multiple machines & platforms), and allow revision control and coexistence of packages, a particular weak point of python in my experience (I could be just doing things wrong). I am interested now in how such versioned packages could be agregated and made avaliable through a centralised service such as PyPi/CPAN, and as to wether such functionality described below will be a spanner in the works for distrobution techniques.

---------my actual question ------------------
To people familiar with distrobuting python projects, and associated tools, eg (py2exe, disutils, PyPi, freeze, etc)
Which is not my string point in python, is this going to cause headaches with the way the afore mentioned tools work.

Can this below  mentioned versioning/package retrieval/recipe retrieval be easily integrated with a CPAN like service such as PyPi & http://python.org/peps/pep-0273.html in a logical manner, allowing platform specific, versioned packages to be agregated and made available automagically at time of import, or through some form of dependancy checker.
------------------------------------

-----functionality------------
This is similar to a technique seen in PythonMegaWidgets and a discussion I found of David Aschers on versioning.
I have made my intial version of this avaliable on aspn.
This is comprised of two parts, versioner.py & version_loader.py (http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/285215), versioner walks a site-packages tree identifying folder structures where versioned packages occur, and distrobutes version_loader.py as __init__.py in the parent folder of this versioned packages, it also creates empty placeholder __init__.py's & autoloaders (from foldername import * - where script name = folder name and no __init__.py exists ) so that you can automagically have "from package.folder.folder.script import method, etc ,etc"
Admittedly Mark Hammonds win32, win32com, etc, didn't work at first inspection but I am happy for such packages to remain locally with site-packages as these are not cross platform packages anyhow, however all other packages I have migrated to my versioned site packages directory have played nicely in tests made. 
(for example: bsddb3, ClientCookie, DCOracle2, Ft, id3, log4py, logging, mx, OpenSSL, PIL, psyco, psyco2, PythonMagick, soaplib, wxPython, xmlplus )
With the manual hack of dragging any built binaries (.so, .dll, .pyd, etc) for said package from DLLS,etc into versioned package folder (OK when this is dpendant on system services eg MySqld, BerkleyDB, etc this could get difficult).

The impact on python syntax for this is minimal with local variables such as:

_foo_version_ = '1.2.3.4' #where point depth is level of compatibility required
import foo

Optionally. _python_version_ = '2.2.2' #again point depth is variable

I further intend to remove all of the pollution this make of local namespace once the import has been performed.
And have not gone through extensive testing nor bug fixes as yet, but all seems to work quite nicely.

Ultimately I would love an extension to the python core syntax along the lines of:

import foo version 2.3.4.5 (with inate platform inspection suffixing on package name)#to give the behaviour I have implements

I thought I had seen a PEP on this though cant seem to find this.

------------------------------------

------------extension to this------------
Ultimately I would like to achieve a CPAN like web retrieval of versioned packages/scripts which are referenced yet not available, though doing this at time of import perhaps if local variable is declared: e.g. _PyPi_download_ = 1, where if a version is specified it will retrieve that version else defaulting to latest.

I would like to extend this with recipes as well,

Eg.

import recipe.aspn_python.stringutil.md5hash as md5hash
import recipe.parnassus.stringutil.utf8escape as ut8esc
import recipe.claysstuff.stringutil.utf8unescape as ut8unesc

Where one could register a base foldername, and their lookup service with a central weblookup services which fires a search for a packge/module/scriptname which returns standardised xml results, to allow retrieval of the said package, storing it in the path you have nominated for versioned-packages/recipes (perhaps in site.py), perhaps even allowing syntax to import all packages from source/category/subcategory/etc eg aspn_python.category.*

Having PyPi agregate packages (perhaps with unit tests also) and mirror seems logical, bundling all immediate depandancies within a single archive also seems logical.

Having packages also nominate dependancies could be a huge benifit:

Eg. requires['package'] = '1.2.3'

Or standard dependancies.xml in base folder of package, ok this may be simplistic, modelling dependancies is a whole separate issue but for example
<depandancies>
        <python version='2.2.2'/>
                <built-against>libpthread.so.0</depend> #using ldd 	
        </python>
        <platform os='linux' distro='shrike'>
                <service name='gcc' version='3.22'/> #using locate(if present) | binaryName -v [perhaps this is a little flimsy]
                <service name='php' version='4.2'/>
        </platform> 
        <packages>
                <name='proprietarycode.foo' version='1.2.4' service='http://foo.com/lookup.cgi|php|etc' user='root' pass='secret'/> #for private packages
                <name='aspn.util.bar' version='1.2.4'/> #uses Pypi to get search service to locate/download package
        <packages>
</depandancies>
------------------------------------

I thought I may as well put out some of the concerns I came across with versioned package managment, and some of the enhancements I could see being of benifit for discussion.
My apologies if I have missed such discussions in these groups I have only recently joined these groups.
Apologies if any of these seems unclear