package including all dependencies for win32

[zooko]

It would be nice to build a package for Windows which includes all dependencies so that people can install Tahoe without having to install any dependencies. See ticket #242 -- "binary package for w32" -- for the first step. The second step is to build a package that contains all the dependencies as well as Tahoe itself.

One could use [py2exe ​http://py2exe.org] for this, but if I'm the one implementing this I will first try to use distutils/setuptools. For example, we could install all of the dependencies and tahoe into the same directory (with --prefix/--single-version-externally-managed), then use distutils/setuptools's "bdist_wininst" or "bdist_msi" feature to build a Windows installer that contains all of that code.

Note that this ticket is not about making a user-friendly application on Windows (that's the subject of ticket #195 -- "user-friendly installer for Windows -- for my Dad!"). This ticket is about a package targeted at programmers (e.g. Samantha) who want to start using Tahoe through the wapi/wui or cli with minimal time spent installing dependencies.

[robk]

From the discussion yesterday, the focus of this is specifically working towards building an installer, and hence tahoe distribution, geared towards end users. While the initial builds will not include all the niceties required for shipping to end users, that goal is the purpose of this packaging.

From a quick look at what bdist_wininst seems to be doing (specifically it seems to be a thin .exe wrapper mechanism for installing a projects source code into an existing python install on windows), I think that py2exe (i.e. building binary .exes, including services, for windows from python source) is definitely the better strategy of the two for the goals in mind.

[zooko]

See also trac ticket #195.

So the limitation of the bdist_wininst method is that it doesn't include a python interpreter, and it doesn't provide a feature of installing services?

[robk]

while it remains the case that there's a 'gotcha' in re .egg packaging (*) the windows build process, which spits out an installer (c.f. #195), encompasses py2exe (c.f. #242) and hence is including all the binary dependencies into an easy to use package which provides, amongst other things, a tahoe client node running as a service which provides a webapi interface.

(*) the gotcha is that py2exe cannot traverse .egg files to extract the sources it finds dependencies upon. it can handle .egg directories just fine, since they can be considered simply as python module directories as far as sys.path and contained .py files are concerned. the net effect is that if you have python dependencies installed in site-packages as .egg files, then the py2exe build will fail. the tahoe build process will successfully and correctly build any dependencies it manages as .egg directories, but it will not bother doing so for dependencies satisfied from site-packages.