On Dec 8, 2004, at 12:20 AM, Mike Taylor wrote:
There are several issues that would have to be hammered out, here. Versioning, for example, both in the sense of formats and qualifiers, and in the sense of versioning a module/package versus versioning a distribution. Gathering information about imports is also tricky. Tools like py2exe try to gather some of this information automatically, but that info doesn't include version requirements. (It may be that we can get by without version requirements, taking the default state to mean, "any version will do.")
If we require that modules specify a __version__ that is a "constant", it would be easy to parse... When you "link" this bundle, it could automatically say that it requires a version >= to the version it saw when it was scanned for dependencies (unless explicitly specified to be more or less specific).
In any case, I think versioning is a really hard problem, especially in Python due to sys.modules and the import mechanism, so I think that this task should be deferred. If Python developers really felt strongly about this, we'd probably see more packages with version numbers in their names :)
The only issue I see with versioning would be if you have a plugin that is operating specific - then the version information would need to include that metadata.
I don't think that's really a big deal. The real problem, from my perspective, is the interpreter-global sys.modules. Sure, you could get around it, but only if you replace Python's import machinery entirely (which you can do, but that is also interpreter-global).
For example, let's say I have barPackage that needs foo 1.0 and bazPackage that needs foo 2.0. How does that work? foo 1.0 and foo 2.0 can't both be sys.modules['foo'].
-bob
_______________________________________________ Distutils-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/distutils-sig
