[Distutils] EasyInstall: Issue: installing versioned modules by default, specifying version at runtime, lazy load highest by default.

[Phillip J. Eby]

At 01:35 PM 6/17/2005 +0100, Clayton Brown wrote:
>Sometime ago, well at least before this modern marvel of eggs/easy
>install etc, I wrote / adapted a bootstrap loader to enable module
>versioning / specification at time of import, its default behaviour
>was to load the highest version at the level of specification eg.
>
>_foo_version__ == "1.2.3" will load 1.2.3.99 etc where one exists
>but no specification will import 99.99.99.99 etc.
>
>ref: http://claytonbrown.com/cbwiki/ModuleVersioning /
>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/285215
>
>could the easy_install / import mechanism accomodate such installation
>/ import hooks, (perhaps by just importing a module to invoke this
>behaviour) so that by default eggs are all installed and versioned,
>and if no version is specified by using require the highest version is
>loaded, and when require() is used unless exact version is specified
>it will import higher versions at the depth of specification should
>they become available. Though by the looks of pkg_resources.require()
>this may just be for system binary dependancies, not modules.
>
>my idea is that it would be nice to use -m on every installed package
>to get versioned modules in site-packages, but not force require()
>within scripts,just default to importing highest released version if
>require() doesn't specifify a differnet version.

When EasyInstall installs a script, it actually installs a stub that 
effectively require()s the coresponding egg, then runs the original 
script.  So, you don't actually have to use require() at all, if you use 
EasyInstall to install some existing project's distribution.  The exact 
version that supplied the scripts will be require()d for you automatically.

require() is really only intended to bootstrap activation of the script's 
distribution; it isn't intended to be used throughout an application 
anyway.  One very important reason why not, is that require() embedded in 
modules is not discoverable.  There is no way to automatically find out 
what versions of things a package requires, and thereby automatically 
install those versions, if it is buried in code.  This is why eggs have a 
depends.txt file where all the dependencies are centrally listed, allowing 
automated tools to deal with them.  These dependencies are based on project 
names, not on individual modules or packages, because project names are 
discoverable (e.g. via PyPI) and package names are potentially far more 
numerous.

So, although your approach has lots of merit, it doesn't accomplish the 
larger goal for Eggs, which is to support upgradeable applications and 
application servers, and to make it easy to add/remove Python packages from 
an application or Python installation.  Versioned importing is just the tip 
of the iceberg for eggs, something that almost falls out as a side effect, 
rather than being a direct goal.  Really, eggs more have the goal of 
*eliminating the need* for versioned importing, rather than implementing 
it!  :)