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.
robk-tahoe [Thu, 10 Jan 2008 22:26:19 +0000 (15:26 -0700)]
fix nevow build prob for py2exe
nevow attempts to use pkg_resources to find the formless css file upon
import, if pkg_resources is available. unfortunately using pkg_resources
to find files is not supported if the files are being loaded from a zip
archive (i.e. only source and egg), and further py2exe uses a zip bundle
for all the code and dependent libraries. hence having both pkg_resources
and nevow built into an exe causes nevow to explode upon import.
this tells py2exe not to link pkg_resources into the target, so that
this behaviour isn't stimulated. the side effect being that pkg_resources
isn't available.
robk-tahoe [Thu, 10 Jan 2008 22:23:41 +0000 (15:23 -0700)]
added tweaked sibpath implementation
use of twisted.python.util.sibpath to find files relative to modules doesn't
work when those modules are bundled into a library by py2exe. this provides
an alternative implementation (in allmydata.util.sibpath) which checks for
the existence of the file, and if it is not found, attempts to find it relative
to sys.executable instead.
robk-tahoe [Thu, 10 Jan 2008 02:54:12 +0000 (19:54 -0700)]
add 'run' command to tahoe
adds a 'run' commands to bin/tahoe / tahoe.exe
it loads a client node into the tahoe process itself,
running in the base dir specified by --basedir/-C and
defaulting to the current working dir.
it runs synchronously, and the tahoe process blocks until
the reactor is stopped.
robk-tahoe [Thu, 10 Jan 2008 02:25:38 +0000 (19:25 -0700)]
add build dependencies to support py2exe's modulefinder
adds windows/depends.py as a container for modules which are needed at runtime
but which py2exe's modulefinder dependency analysis fails to find as requisites.
robk-tahoe [Thu, 10 Jan 2008 02:19:52 +0000 (19:19 -0700)]
added a 'repl' command to tahoe.exe
this is probably not of very high utility in the unix case of bin/tahoe
but is useful when working with native builds, e.g. py2exe's tahoe.exe,
to examine and debug the runtime environment, linking problems etc.
robk-tahoe [Thu, 10 Jan 2008 02:02:53 +0000 (19:02 -0700)]
tweaks to build process to support py2exe
py2exe is unable to handle .eggs which are packaged as zip files
in preference it will pull in other versions of libraries if they
can be found in the environment.
this changes causes .eggs to be built as .egg directories, which
py2exe can handle.