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.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
