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

[Mike Taylor]

I'm also interested in this idea.  While I'm new to the distutils 
scene, I am currently tasked with creating installation tools for 
Chandler so maybe I can be of some help.

On Dec 7, 2004, at 11:50 PM, Bob Ippolito wrote:

>> * Update URL (for obtaining the "latest" version of the plugin)
>
> How about some kind of public key as well, so that if you visit the 
> update URL you will know if the new package was provided by the same 
> author or not?

Some sort of signature, or other means of validation, would be a must - 
otherwise the security risk would make cross-site scripting attacks 
look enjoyable :)

>> 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.

>> Platform specs are another dicey issue, since we're talking about 
>> trying to define binary compatibility here.  This includes the issue 
>> that it might be necessary to include shared libraries other than the 
>> C extensions themselves.  (For example, like the wxWidgets libraries 
>> that ship with wxPython.)
>
> The only reasonable solution I've found to this issue is to just shove 
> every dependency in the package.. any less than that and it's just too 
> hard to deal with.

I took a good look at how to make Chandler be able to use existing 
modules/libraries in order to reduce the number of included 
dependencies and ended up putting the idea down and just backing slowly 
away from it.  Without the metadata information that this idea would 
provide it just seems to be one big mess.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://mail.python.org/pipermail/distutils-sig/attachments/20041208/f1bc185f/PGP.pgp