robk-tahoe [Thu, 24 Jan 2008 01:22:23 +0000 (18:22 -0700)]
eliminate startup spam for resources that can't be found
remove debug messages (and traceback) from node output in the case that the
pkg resources hook can't find a requested file. it will now silently return
the empty string for files that can't be resolved
robk-tahoe [Thu, 24 Jan 2008 01:05:56 +0000 (18:05 -0700)]
fix tahoe script installation logic
refine the logic in the .app which tries to install the 'tahoe' script.
now it will do nothing if 'tahoe' is found anywhere on the user's path,
and only if it's not present will it try to install it in each of the
candidate paths (/usr/local/bin ~/bin ~/Library/bin) which are on the
user's path
robk-tahoe [Wed, 23 Jan 2008 22:17:27 +0000 (15:17 -0700)]
fix windows build
having changed the web template retrieval to use nevow.util.resource_filename
(and hence through pkg_resources when available) that adds a requirement that
py2exe be given a hint to induce it to include the allmydata.web module so that
it becomes importable.
setup: weaken the requirement on zope.interface from >= 3.1.0 to "any"
We've never heard of a version of zope.interface that *wasn't* compatible, and there is a bug in Ubuntu's packaging of zope.interface which causes it to report its version number as 0.0.0:
setup: loosen our requirement on pycryptopp from >= 0.2.9 to >= 0.2.8
Again, tahoecs2 has pycryptopp v0.2.8, and reviewing the pycryptopp change history shows that there were no important bugfixes added since 0.2.8.
robk-tahoe [Wed, 23 Jan 2008 03:35:01 +0000 (20:35 -0700)]
have mac app write a tahoe upon startup
upon startup, the .app will look in '/usr/local/bin', '~/bin', '~/Library/bin'
if it finds one of these dirs, and can write into it, and there isn't already
a 'tahoe' present, it will write a small bach script which will launch the
binary contained within the .app bundle
this allows the .app bundle to offer the services of the 'tahoe' script
easily and simply
robk-tahoe [Wed, 23 Jan 2008 02:32:55 +0000 (19:32 -0700)]
fix build breakage caused by auto_deps setuptools stuff
zooko recently added a runtime check, via setuptools, that specific versions of various
packages were reported as available through setuptools at runtime.
however exe and app builds run with collected egg contents, not linked against entire
eggs, i.e. the code is transcluded into a single library.zip
thus setuptools reports that those specific version cannot be reported as available,
though they are in fact available built into the library
this disables that runtime check if the app is running 'frozen'
robk-tahoe [Wed, 23 Jan 2008 02:32:26 +0000 (19:32 -0700)]
add mac native build
This patch adds support for a mac native build.
At the moment it's a fairly simple .app - i.e. so simple as to be unacceptable
for a shipping product, but ok for testing and experiment at this point.
notably once launched, the app's ui does not respond at all, although its dock
icon does allow it to be force-quit.
this produces a single .app bundle, which when run will look for a node basedir
in ~/.tahoe. If one is not found, one will be created in ~/Library/Application
Support/Allmydata Tahoe, and that will be symlinked to ~/.tahoe
if the basedir is lacking basic config (introducer.furl and root_dir.cap) then
the wx config wizard will be launched to log into an account and to set up
those files.
if a webport file is not found, the default value of 8123 will be written into
it.
once the node has started running, a webbrowser will be opened to the webish
interface at the users root_dir
note that, once configured, the node runs as the main thread of the .app,
no daemonisation is done, twistd is not involved.
the binary itself, from within the .app bundle, i.e.
"Allmydata Tahoe.app/Contents/MacOS/Allmydata Tahoe"
can be used from the command line and functions as the 'tahoe' executable
would in a unix environment, with one exception - when launched with no args
it triggers the default behaviour of running a node, and if necessary config
wizard, as if the user had launched the .app
one other gotcha to be aware of is that symlinking to this binary from some
other place in ones $PATH will most likely not work. when I tried this,
something - wx I believe - exploded, since it seems to use argv[0] to figure
out where necessary libraries reside and fails if argv[0] isn't in the .app
bundle. it's pretty easy to set up a script a la
#!/bin/bash
/Blah/blah/blah/Allmydata\ Tahoe.app/Contents/MacOS/Allmydata\ Tahoe "${@}"
robk-tahoe [Wed, 23 Jan 2008 00:44:58 +0000 (17:44 -0700)]
tweak webish to use resource_filename to find css and html files
using sibpath to find web template files relative to source code is functional
when running from source environments, but not especially flexible when running
from bundled built environments. the more 'orthodox' mechanism, pkg_resources,
in theory at least, knows how to find resource files in various environments.
this makes the 'web' directory in allmydata into an actual allmydata.web module
(since pkg_resources looks for files relative to a named module, and that module
must be importable) and uses pkg_resources.resource_filename to find the files
therein.
setup: make find_trial self-contained so that we don't have a bootstrapping problem -- if allmydata can't be imported we still want to be able to run find_trial
setup: require specific versions of dependencies, both at run-time (if pkg_resources is available) and at build-time, and make there be only once place where we specify those versions
Using pkg_resources.require() like this also apparently allows people to install multiple different versions of packages on their system and tahoe (if pkg_resources is available to it) will import the version of the package that it requires. I haven't tested this feature.
setup: for reasons that I do not understand "show-eggspath" gives me a GNUmake error unless I move it down a couple of stanzas (until after the stanza that sets PYTHONPATH)
setup: add a setup.cfg file which instructs setuptools to install all eggs in unzipped form and to always copy them into the target directory (even if they are already installed somewhere else on the path that setuptools searches, which includes the CWD)
robk-tahoe [Mon, 21 Jan 2008 22:25:15 +0000 (15:25 -0700)]
offloaded: reinstate fix for windows tests
in a discussion the other day, brian had asked me to try removing this fix, since
it leads to double-closing the reader. since on my windows box, the test failures
I'd experienced were related to the ConnectionLost exception problem, and this
close didn't see to make a difference to test results, I agreed.
turns out that the buildbot's environment does fail without this fix, even with
the exception fix, as I'd kind of expected.
it makes sense, because the reader (specifically the file handle) must be closed
before it can be unlinked. at any rate, I'm reinstating this, in order to fix the
windows build
robk-tahoe [Mon, 21 Jan 2008 22:13:10 +0000 (15:13 -0700)]
update confwiz to include account creation ui
this changes the confwiz so that hitting the 'create account' button, rather than
opening a webbrowser to the register page, instead provides a simple account creation
ui directly, along with changes to the backend (native_client.php) to support that.
also added a 'connecting...' message so the user sees a response when they hit
login or create account, since the getBasedir call can sometimes take up to ~5min
(which is unacceptable for a user product, but this at least somewhat ameliorates
the issue of the ui locking up and not giving the user any feedback while it's
happening)
setup: it is okay to leave src/allmydata_tahoe.egg-info in place
This directory allows programs to programmatically identify tahoe and its version number while "running from source" -- i.e. using ./setup.py develop.
setup: simplify the setup by removing the "tahoe dependencies" fake project
Now we use "./setup.py develop" to ensure that changes to our source code are immediately used without requiring a "make" step. This simplification will hopefully pave the way for easier py2exe and py2app, solving the "Unit tests test the installed version" bug (#145), and perhaps also #164 and #176.
This patch also conditionalizes the use of setuptools_darcs on the absence of a PKG-INFO file, which is part of fixing #263.
doc: architecture.txt: start updating architecture.txt
I chose to remove mention of non-convergent encoding, not because I dislike non-convergent encoding, but because that option isn't currently expressed in the API and in order to shorten architecture.txt. I renamed "URI" to "Capability". I did some editing, including updating a few places that treated all capabilities as CHK-capabilities and that mentioned that distributed SSKs were not yet implemented.
doc: add an overview to about.html
Hopefully this overview has the right combination of generality and precision to satisfy The Norm Hardy Request:
http://allmydata.org/pipermail/tahoe-dev/2007-November/000222.html
robk-tahoe [Fri, 18 Jan 2008 03:57:29 +0000 (20:57 -0700)]
offloaded: fix failure in unit test on windows
in trying to test my fix for the failure of the offloaded unit test on windows
(by closing the reader before unlinking the encoding file - which, perhaps
disturbingly doesn't actually make a difference in my windows environment)
I was unable too because the unit test failed every time with a connection lost
error.
after much more time than I'd like to admit it took, I eventually managed to
track that down to a part of the unit test which is supposed to be be dropping
a connection. it looks like the exceptions that get thrown on unix, or at
least all the specific environments brian tested in, for that dropped
connection are different from what is thrown on my box (which is running py2.4
and twisted 2.4.0, for reference) adding ConnectionLost to the list of
expected exceptions makes the test pass.
though curiously still my test logs a NotEnoughWritersError error, and I'm not
currently able to fathom why that exception isn't leading to any overall
failure of the unit test itself.
for general interest, a large part of the time spent trying to track this down
was lost to the state of logging. I added a whole bunch of logging to try
and track down where the tests were failing, but then spent a bunch of time
searching in vain for that log output. as far as I can tell at this point
the unit tests are themselves logging to foolscap's log module, but that isn't
being directed anywhere, so all the test's logging is being black holed.
Brian Warner [Thu, 17 Jan 2008 08:16:56 +0000 (01:16 -0700)]
offloaded: upload.py: handle forward skips, to allow resumed uploads to send less than all the data. We still read all the data (to hash it, 'paranoid mode'), but we don't send it over the wire
Brian Warner [Wed, 16 Jan 2008 10:03:35 +0000 (03:03 -0700)]
megapatch: overhaul encoding_parameters handling: now it comes from the Uploadable, or the Client. Removed options= too. Also move helper towards resumability.
robk-tahoe [Thu, 17 Jan 2008 03:29:30 +0000 (20:29 -0700)]
simplify buildbot upload of windows installer
since the installer upload got more complex (needing to chmod files before
rsyncing) I promoted it to a makefile target, simplifying the buildbot steps
involved
robk-tahoe [Thu, 17 Jan 2008 02:15:35 +0000 (19:15 -0700)]
add winfuse plugin to installer
this adds the latest build of mike's winfuse plugins, now also running as
a windows service (and using the node.url, private/root_dir.cap files from
the noderoot specified by the registry) into the install process.
robk-tahoe [Tue, 15 Jan 2008 23:59:41 +0000 (16:59 -0700)]
tweak py2exe setup.py to link in xmlplus iff present
so in the build slave's environment, everything builds and runs fine without
'_xmlplus'. In my existing local environment everything builds and runs only
if I tell py2exe to explicitly link in '_xmlplus'.
the _xmlplus module, tested for by the python standard library, comes from
PyXML ( http://pyxml.sf.net ) a project which is no longer maintained and,
for instance, hasn't released a build for windows past python 2.4
hence something about the way nevow and the std lib import xml dependencies
causes build environment incompatabilities between my box (which is running
py24 currently) and the buildslave (which is on py25, and doesn't have PyXML)
(if I remove _xmlplus from my environment, then a different set of nevow/xml
import problems emerge, which do not occur in the buildslave's py25 env)
this change tests the environment the build is happening in, and if the
_xmlplus package is importable, then py2exe is directed to link it into the
build. otherwise the package is left out. as far as I comprehend the issue
this should make both of these environments work. if other people have
problems around this issue, obviously I'm interested in learning more.
robk-tahoe [Tue, 15 Jan 2008 00:53:54 +0000 (17:53 -0700)]
windows installer build refinements
this resolves problems of py2exe's modulefinder collection of sources from
.zipped egg files, not by using easy_install to reach the --always-unzip
option, but rather with a small tool which unpacks any zipped egg files found
in misc/dependencies. this fixes the py2exe build given rollback of the
easy_install stuff which had broken the unix builds. misc/hatch-eggs.py
performs the honours.
this also includes a misc/sub-ver.py tool which substitutes elements of the
verion number for the current code base (by importing allmydata.__version__
hence make-version should be run first, and the python path carefully managed)
into template files using python's string interpolation of named args from a
dict as the templating syntax. i.e. %(major)d %(minor)d %(point)d %(nano)d
each expand to the individual components of the version number as codified
by the pyutil.version_class.Version class. there is also a %(build)s tag
which expands to the string form of the whole version number. This tool is
used to interpolate the automatically generated version information into the
innosetup source file in a form consistent with innosetup/windows' restrictions
robk-tahoe [Sat, 12 Jan 2008 03:41:21 +0000 (20:41 -0700)]
add windows installer target to build
add 'windows-installer' target to top level makefile to build a windows setup.exe package
using innosetup. this assumes innosetup 5 is installed in program files as normal.
this doesn't include any logic to manage version numbers at this point, it's just a
simple experiment to test out building an installer as yet.
robk-tahoe [Sat, 12 Jan 2008 02:53:15 +0000 (19:53 -0700)]
implement a very simple, wxpython based, config wizard
This implements a very small app using a wx ui to log a user in.
it takes a username and password, and submits them to a backend on the web site
(currently the allmydata test net webserver) to authenticate them. It returns
the 'root_cap' uri of the user's virtual drive. Also the introducer.furl is
retrieved. These are then written into the default noderoot basedir in their
usual files (private/root_dir.cap and introducer.furl)
a button is provided which will direct the user to the web site in the event
that they need to register in order to have an account to use.
once the user is successfully authenticated and the files are written, then
on win32 the tahoe service will be started.
Brian Warner [Tue, 15 Jan 2008 05:31:41 +0000 (22:31 -0700)]
test_GET_DIRURL_large: reduce from 400 to 200 children: the test fails to
fail anyways, and 200 ought to be enough to trigger the problem, so 400 is
overkill, and just wastes CPU.
setup: switch back from using "misc/dependencies/setup.py easy_install --always-unzip misc/dependencies" to using "misc/dependencies/setup.py install"
because I don't fully understand the former, I suspect it of being implicated in the current buildslave redness, and we require --always-unzip solely for py2exe.