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

[Paul Moore]

2009/4/10 zooko <zooko at zooko.com>:
> 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.)

First of all, thanks for actually trying this. It's interesting to see
a non-Windows user's reaction to the process.

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

Hmm, and this is *precisely* one of the things I dislike. I don't like
anything being installed except on my request. Consider the strawman
case of a hacker managing to add a dependency to some malicious
package into a package you depend on. Or more realistically, the audit
implications of having to manually inspect all the setup files of the
transitive closure of packages your package depends on - you have a
similar problem with manual dependency handling, but at least then you
simply have to read the documentation, and can rely on the fact that
nothing gets installed that you don't explicitly request.

But that's certainly a personal view.

> 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.

And yet, you'll get Debian users who say your install process doesn't
work for them because it doesn't use apt, and doesn't register the
packages in the apt database. And Windows users who'll point out that
it doesn't work behind their corporate firewall, etc.

One person's "works" is another's "irritating failure to conform to
local standards". Preference again :-)

> 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 have been told that bdist_wininst installers do all that eggs do.
The entry point mechanism is one area I wonder if that's true - but
I've yet to test it myself, largely because I find the documentation
for setuptools stunningly impenetrable :-( If eggs do support
executable scripts where bdist_wininst doesn't, that is indeed a win,
as script handling is a real wart with bdist_wininst. (But please
note, I'm talking eggs vs bdist_wininst, not easy_install vs
bdist_wininst). Actually, your experiment below shows that
bdist_wininst does this fine.

> 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.

Agreed. But as long as developers don't distribute bdist_wininst
installers as well as eggs, they are forcing the two to be
alternatives, rather than complementary.

[...]
> It works!  Cool!

Glad it impressed you (at least somewhat :-))

>  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.

I'm very wary of saying what other users want, but it does fit what
*I* want. But you need to understand that I only use it for installing
packages into my system Python (for use when writing standalone
scripts, or interactive use at the interpreter prompt).

For *applications*, on Windows I would expect a py2exe-packaged
standalone application, with all its dependencies (including Python)
bundled in. It sounds like that's what Tahoe is, and as such I'd not
be trying to install it into my site Python installation. If I was a
Tahoe user, and it had installed into my Python installation, then I'd
be hugely annoyed if (say) upgrading or uninstalling Twisted caused
Tahoe to break (I don't know if Tahoe uses Twisted, one of my gripes
is that it's not clear from the Tahoe web page precisely *what* it
depends on, and hence what I'd have to be careful to avoid fiddling
with...)

>  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.

Why? If your users want it and/or it's simple for you to produce *in
case* a potential users wants it, then why do you refuse to distribute
it simply because you don't like the user experience it offers?

Anyway, thanks again for actually trying all this. I think I
understand your POV a bit better now. And you may want to investigate
py2exe as a distribution option more suited to your Windows users'
expectations (but py2exe does, I believe, only run on Windows, so it's
not a cross-platform option, sadly).

Paul.