in justin's testing, the uninstall tracking was hanging the uninstall
process (on vista) for now, until we see enough need for it to warrant
more detailed testing/debugging/tweaks, I'm simply disabling the call
to confwiz --uninstall
also this adds a 'welcome page' to the install process. once the user
has installed the windows build, then the installer will open a web
browser to the 'welcome page' on the website ('/welcome_install')
this moves some of the code common to both windows and mac builds into the
allmydata module hierarchy, and cleans up the windows and mac build directories
to import the code from there.
now that web templates are found via pkg_resources, then the windows build
should in fact _use_ pkg_resources, rather than exclude it from the build
to prevent nevow exploding upon import due to the zip provider exception,
so that the pkgreshook can do install location based lookups
the recent changes to webish's template lookup (to use nevow.util hence
pkg_resources) to support the mac build, needs these changes to the windows
build in match the new lookup path
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.
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)
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.
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.
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.
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.
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.
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.
