[Twisted-Python] Twisted plugins and py2exe

glyph at divmod.com glyph at divmod.com
Tue Feb 24 14:55:05 EST 2009

On 04:55 pm, exarkun at divmod.com wrote:
>Tue, 24 Feb 2009 17:35:14 +0100, Gabriel Rossetti 
><gabriel.rossetti at arimaz.com> wrote:
>>Jean-Paul Calderone wrote:
>>>On Tue, 24 Feb 2009 11:49:13 +0100, Gabriel Rossetti 
>>><gabriel.rossetti at arimaz.com> wrote:

>>>>Has anyone ever had this problem while using plugins with Twisted 
>>>>and py2exe?

>>>No, but from the traceback, it seems fairly clear that the plugin 
>>>is trying to write a plugin cache file into your py2exe-created zip 
>>>of Python source.

>>Ok, I could do this, teach it abot zip files and have it update it's 
>>cache in the zip file, but in certain cases, like mine actually, if 
>>you tell py2exe to include the zip file in the exec, then it won't 
>>work. How about adding the possibility to specify where the cache is 
>>to be written?

This is almost certainly the wrong solution to your problem, but if you 
disagree with this assessment please feel free to update this ticket:


Several people have requested this feature and nobody has really made a 
good case for why it should be implemented.  (I don't think it should 
be, I just think we should record all the reasons why not on that ticket 
>Updating the cache in the zip file probably isn't the right thing to 
>Just skipping cache generation would probably make more sense.  It 
>be easier to implement, anyway.

Skipping the cache generation is like skipping bytecode compilation. 
It's not a catastrophic error, everything should still work, but it will 
result in more unnecessary work being done at runtime.

IMHO the right solution in this particular case would be to get py2exe 
(or some part of the setup process in py2exe, which I believe is 
implemented using distutils) to generate a cache file as part of the 
built zip file.  Presumably .pyc files are also created and included in 
the zip file.  The appropriate procedure for forcibly generating the 
cache is described here:


A cache generated in this manner will be suitable for packaging into a 
zip file.

Another part of the solution would be to implement setContent on 
ZipPath.  However, there are still likely to be erroneous deployment 
scenarios where the ZipPath is not available for writing, just as an 
installation path is frequently not available for writing now.  So an 
initial implementation of setContent on ZipPath could just raise the 
same exception that an unwritable FilePath would, for consistency in 
error handling.

For the issue of quieting the mostly-harmless error message now produced 
by a failure to write the cache file, see here:


More information about the Twisted-Python mailing list