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! :) _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
