[Distutils] Standardizing distribution of "plugins" for
bob at redivi.com
Wed Dec 8 07:51:56 CET 2004
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
>> 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'].
More information about the Distutils-SIG