[Distutils] Standardizing distribution of "plugins" for extensible apps

[Bob Ippolito]

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