[Distutils] Distutils changes - end user requirements (Was: Deprecate MANIFEST.in)

[zooko]

> Can any packager step up and explain why they execute "python  
> setup.py bdist_egg" rather than "python setup.py bdist_wininst"  
> when creating distributions for their Windows users?

For starters, the former works on all my development platforms.  I  
can script buildbot to do it the same on all platforms, for example.   
The latter I haven't tried.  Just a minute...  <Zooko tries "python  
setup.py bdist_wininst".>   (See appendix A.)

Secondly, the package can be automatically installed when the user  
easy_installs a *different* package which depends on my package.

The Tahoe project currently has fourteen such dependencies.  The  
Tahoe install process works on all platforms including Windows:

http://allmydata.org/source/tahoe/trunk/docs/install.html

It isn't perfect, but I think it is pretty cool that the same install  
document works for both Windows users and everyone else.

Thirdly, the entry_points mechanism for making executable scripts  
means I get executable scripts on all platforms with no extra effort  
on my part.

I'm not saying that this is perfect, or that users don't want other  
things, or that developers shouldn't want other things.  For Tahoe in  
specific, I really would like a normal installable package thing like  
Windows users expect for their apps.  But until someone offers to  
spend their time crafting such a thing for Tahoe (ideally by using  
the bbfreeze tool [1] to automatically generate one from the Tahoe  
source distribution), I'm happier with what I've got now than with  
the alternative, which is a long list of around sixteen -- sixteen!  
-- different packages that the user would have to manually install  
before they can install Tahoe, where each of them might have  
different special install instructions on any of a dozen different  
supported platforms.

Again, the setuptools-based system that Tahoe has now is not  
*alternative* to Windows-specific installers or Debian-specific apt- 
get'able packages.  In fact, hopefully they will become increasingly  
*complementary* as tools like stdeb and bbfreeze mature.

Regards,

Zooko

[1] http://allmydata.org/trac/tahoe/ticket/585 # make it work with  
bbfreeze

Appendix A:
Let's see, "python setup.py bdist_wininst" produced a file which I  
then uploaded to my web server: http://zooko.com/allmydata- 
tahoe-1.3.0-r3833.win32.exe.  When I run that file, it first pops up  
a security warning that the producer of this file (me, in fact) is  
untrusted.  Once I hit the button labelled "Leave me alone about your  
stupid security warnings" then it enters the normal installation  
wizardy thing.  It has all my package metadata nicely displayed on  
the first page.  Cool!  Then it asks me which python to use -- it  
found 2.5 and 2.6 on my system.  I choose, then click "install", then  
"finish" and it goes away.

Now what?  Let's see, it didn't add anything to my Start Menu.  I see  
that it installed it into c:/Python26/Lib/site-packages/allmydata ,  
(which is the name of the top-level module in the allmydata-tahoe  
distribution), as well as writing a Removeallmydat-tahoe.exe and a  
allmydata-tahoe-wininst.log file.  Oh!  I see that it made a c:/ 
Python26/Scripts/tahoe.exe file!  Cool.

Okay, but I can't actually use it unless I now go and install a dozen  
or more dependencies (as mentioned in the body of this letter).   
Okay, finally, uninstall.  Hm... It isn't there in the "Add/Remove  
Programs" list.  Oh -- it is named "Python 2.6 allmydata-tahoe-1.3.0- 
r3833" instead of "allmydata-tahoe".  And it worked to remove all the  
files as far as I can tell.

It works!  Cool!  My verdict: as a consumer of other people's  
software, I wouldn't want to use a GUI tool like this if I could help  
it (it takes about 10 times as long to install a package that way as  
on the command-line, you can't script it, and you can't easily  
capture an encoding of all the options which were chosen for later  
reproduction).  I'm sure that many other users would want to install  
applications this way, i.e. things which they actually care whether  
it is installed or not, but I suspect most users do not want to  
install dependencies this way, i.e. things that are there only  
because an application requires it.  As a producer of packages I  
would be happy to use bdist_wininst since it is fully scriptable and  
I can just program my buildbot to do it for me, however I won't do so  
until the resulting installer can either automatically satisfy its  
dependencies or come with its dependencies bundled inside it.