make it work with bbfreeze #585
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#585
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
bbfreeze -- http://pypi.python.org/pypi/bbfreeze -- is an alternative to py2exe and (in the near future) to py2app. It is very easy to use:
Except that it currently doesn't work for Tahoe on Windows -- something about our (very tricky and complicated)
bin/tahoe
hack is outwitting bbfreeze maybe?Unassigning cgalvan since he hasn't been active in a couple of months.
This works for me on 1.6.0:
tahoe.exe is created in dist directory and runs okay.
For me mids' recipe does produce an executable, but it references an
.egg
file that does not contain any resources, such as.xhtml
files. This results in exceptions when trying to view the WUI of a node run using this executable.The exception when viewing the WUI was:
(That file indeed does not exist, although the directory does and contains
.pyc
files.)zooko wrote on IRC:
Replying to davidsarah:
Hey! This was ticket #1033, which has been fixed. Maybe now mids's recipe will work! :-)
Replying to [zooko]comment:7:
If it did before, it won't now, because the windows directory has been removed by #1282.
After much trial and error, I found the following recipe instead. First apply bb-freeze.darcs.patch to a checkout of trunk. Then from a cygwin prompt:
(cygwin is not essential, but we need sed to convert the CRLF line endings in _version.py, otherwise the compiler invoked by bb-freeze will fail to compile it. I don't know why it is so picky.)
The resulting
dist\tahoe.exe
has a bug that causes its argv array to be shifted, droppingsys.argv[0]
. You can work around this by giving 'tahoe' as a dummy first argument.I haven't tested it much, but it can run a functioning gateway node to the pubgrid, and list the public directory using the CLI. Unicode arguments and output even work!
Attachment bb-freeze.darcs.patch (13398 bytes) added
Various hacks to get bb-freeze to mostly work. Do not apply to trunk. refs #585
Attachment bb-freeze.darcs.2.patch (13928 bytes) added
Various hacks to get bb-freeze to mostly work. Definitely do not apply to trunk. This version of the patch includes the workaround of adding as the dummy 'tahoe' argument so you don't need to. refs #585
Replying to [davidsarah]comment:8:
And the WUI works without the resources problem in comment:69020, I meant to say.
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.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+" 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 tostatic/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 importsetuptools
, it can fail to find the originalsite
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 wheneverinstall_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 thatpkg_resources
''attempted'' to put on thesys.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:
(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.
Attachment bb-freeze.darcs.3.patch (41381 bytes) added
Make bbfreeze work. This also refactors allmydata/init.py and _auto_deps.py and implements more robust checking of dependency requirements. It includes a change to the bundled darcsvar, to write the _version.py file with LF line endings.
Attachment static-tahoe.darcs.patch (12074 bytes) added
static/tahoe.py: import mock (for 'tahoe debug trial') and xml.tree.minidom (to avoid noise from twisted plugins). refs #585
With bb-freeze.darcs.3.patch + static-tahoe.darcs.patch + attachment🎫1296:tahoe-debug-trial.darcs.patch , we pass everything except for skipping a few runner tests (which I will fix tomorrow).
Use
dist\tahoe debug trial
to test.In [4938/ticket1306]:
In [4939/ticket1306]:
In [4942/ticket1306]:
In [4943/ticket1306]:
In changeset:93c1909847e9dc44:
I reviewed changeset:93c1909847e9dc44 and it looks good to me.
[20110113043040-93fa1-2a5ccfc48e2fe53b3fa5a91e913fbd300ccd98f4]/ticket1306 looks good. (I eyeballed it but didn't actually copy out the text and use
diff
to confirm that the text didn't get changed while it was getting moved.)[20110107085259-93fa1-386c985e5bebe82119025222c9c39a43aa5b40b4]/ticket1306 looks fine.
Okay I read through [20110113042457-93fa1-b0c23a181f94c19e75407448bdd776c9a065f1a1]/ticket1306. I can't claim to understand it 100%, but I couldn't see any defect or think of any design problem with it. +0.9 :-)
David-Sarah is going to merge these patches into trunk.
In changeset:8587c63bdc291faf:
I'm guessing that changeset:8587c63bdc291faf is meant to close this ticket. Please re-open if I'm wrong.
davidsarah mentioned on IRC about an hour ago that there's one more patch to go in (".tac files import pkg_resources, so that's still a dependency"). Reopening for that.
In changeset:c8ccb297fa7f499d:
The PYTHONPATH is not right in the recipe in comment:69026. Using a Command Prompt, do:
where
<tahoedir>
is the full path to the Tahoe source directory.(
make clean
is only necessary if dependencies have changed.)I'll add this to wiki/AdvancedInstall.