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
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.
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.
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.
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.
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.
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.
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.
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.
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.
there are many and various fiddly details that were involved in this process
on mountain view. This is a stripped down version of the build process used
there. there's hence a good chance that one or two necessary details got
stripped down through the cracks.
this provides a py2exe setup.py to build a tahoe.exe and a tahoesvc.exe
the former is equivalent to bin/tahoe, but without the start/stop commands.
the latter is a windows service that instantiates a client whose basedir
is found in the registry.
