[tahoe-dev] [tahoe-lafs] #585: make it work with bbfreeze

[tahoe-lafs]

#585: make it work with bbfreeze
-----------------------------+----------------------------------------------
     Reporter:  zooko        |       Owner:  nobody                             
         Type:  enhancement  |      Status:  new                                
     Priority:  major        |   Milestone:  soon                               
    Component:  packaging    |     Version:  1.2.0                              
   Resolution:               |    Keywords:  windows install setuptools bbfreeze
Launchpad Bug:               |  
-----------------------------+----------------------------------------------

Comment (by davidsarah):

 I worked out why the arguments are off-by-one -- it is because the code to
 retrieve Unicode arguments in [source:src/allmydata/windows/fixups.py]
 depends on the script having been invoked via the Python interpreter, so
 that {{{unicode_argv[0]}}} (the python executable) needs to be skipped.
 The executable produced by bbfreeze, OTOH, is not invoked via the Python
 interpreter. This problem wouldn't have occurred before the fix to #1074
 in Tahoe v1.8.0, which explains why it worked for mids.

 attachment:bb-freeze.darcs.3.patch (which depends on the patch for #1287)
 has now been updated to solve this problem in a way that doesn't interfere
 with the behaviour of the usual {{{bin/tahoe}}}.

 This attachment also includes a patch to the bundled darcsver, to make it
 write {{{_version.py}}} with LF line endings, by changing "wt+" to "wb+"
 [http://tahoe-
 lafs.org/trac/darcsver/browser/trunk/darcsver/darcsvermodule.py#L50 here].
 This matches all of the other Python source files, so should not cause any
 problems. (We should make a darcsver release, this patch to the bundled
 version is just for testing.)

 {{{windows/tahoe.py}}} has been moved to {{{static/tahoe.py}}} because it
 is not specific to Windows. It should probably work for any
 [http://www.freehackers.org/Packaging_a_python_program static Python
 executable packager], although I haven't tested any others.

 I've changed the patch to only omit the setuptools version and path from
 the output of {{{get_package_versions_and_locations()}}} when running the
 bb-frozen executable (which does not actually have setuptools as a runtime
 dependency). The problem that this is addressing is that if the executable
 tries to import {{{setuptools}}}, it can fail to find the original
 {{{site}}} module and exit at that point.

 I also refactored a bunch of stuff in {{{__init__.py}}} and
 {{{_auto_deps.py}}}. {{{get_package_versions_and_locations()}}} is now in
 {{{_auto_deps.py}}} because it needs to be updated whenever
 {{{install_requires}}} is. It suppresses deprecation warnings while
 importing modules, so that the bb-frozen executable doesn't print these
 warnings. Finally, we now correctly check that the versions of imported
 modules actually satisfy the requirements (except for pyasn1, where we
 don't know the version number). Previously, {{{require_auto_deps()}}} only
 checked that the distributions that {{{pkg_resources}}} ''attempted'' to
 put on the {{{sys.path}}} satisfy the requirements that it was told to
 satisfy. That is not sufficient due to #1246, #1258 and possibly other
 bugs. I needed to simplify the pycrypto requirement to {{{>= 2.3}}}, since
 the new check doesn't support disjunctive requirements.

 The recipe is now:
 {{{
 make clean
 python setup.py build
 export PYTHONPATH=support/Lib/site-packages
 bb-freeze static/tahoe.py
 }}}

 (This should work on a Windows command prompt, modulo availability of
 'make', and set instead of export.)

 We need to be able to test the resulting executable. I will file another
 ticket for that.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/585#comment:10>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage