[Twisted-Python] First impressions of Windows downlod

[Andy Robinson]

I'll try to help with any windows issues I can...ReportLab
are starting to face exactly the same things with packaging
up our commercial products, except we have not really braved
distutils yet. I can see from your setup script that you
have :-)  Nobody on the SIG ever answered any of my questions
so I guess I can learn from you here too...

> I don't understand Microsoft's "DOS Shell" scripting language too
> well, but I
> think "execute" means something misleading in this context,
> i.e. "double-click".  Since most of the Twisted main scripts
> don't have a GUI,
> when you "run" them in the explorer, a black DOS box comes up and
> disappears.

Windows uses file extensions rather than marking scripts
executable, and things like "#!/usr/bin/env python" mean
nothing to it.

You can either type the command line in a DOS box, or double-click
it. If you double-click and a traceback occurs, you won't get to
read it.  It's pretty much understood that for things like web servers,
scripting languages and databases one has to use the DOS prompt
and there will be a bunch of commands to administer the server,
just like on Unix.  The DOS shell in Windows 2000 is very pleasant,
readline-ish, with auto-completion and a host of commands, and any Python
programmer will certainly be used to it.

> Is there some way to make it so that these commands are accessible via the
> user's %PATH% at a DOS prompt, regardless of distutils?  The only
> technique I've found involves Cygwin and that was pretty nasty.

Python is not on the path by default (but see 2 below). As I see it
you've got 3-4 choices on such scripts.
1. If the file has no extension, like your current scripts, you can
still execute it by doing
    python myscript
(assuming Python is on the path).  But it's not intuitive what to
do with a file that lacks an extension.

2. If the file ends in .py, then Windows knows it's a python script
as the .py extension was 'associated' with python.exe when Python
was installed.  You can then run by using its name:

C:\Python22\Lib\site-packages\twisted\scripts>mktap.py web --path
c:\\code\\www_reportlab_com
Saving web application to web.tap...
Saved.

Just like Unix - well, nearly.

3. If a file ends in .bat you can execute it and it's assumed to
have Windows' fairly poor batch language.  There is a horrible
hack to hide Python scripts in batch files, but it's REALLY
horrible.  You could also make a batch file call a Python script,
but it's unusual and pointless since you need the Python script
anyway.

4. If you're devilishly cunning you can make 'stub EXEs', using
a partial binary, and they can be assembled on Unix.  Our commercial
download has a 'bin' directory containing a tiny 'rml2pdf.exe' which
just imports and runs the content of rlextra/rml2pdf/rml2pdf.py(c).

The real problem, of course, is what distutils does now.  I don't
know if it has a post-install hook.  If it does, then you could
do
  if sys.platform == 'win32':
      for filename in os.listdir('bin'):
          os.rename(filename, filename + '.py')

If not, I wonder if you can do that when making the package?
This would instantly make sure that they were executable
and also obviously recognizable.

>
> FWIW I don't think it's possible to do run any post-installation
> code on win32
> with distutils.  I haven't looked in depth for a while, but I
> haven't heard
> news of this being fixed, either.
Doh, there goes that idea then.

> Yes.  I'm glad you see the utility in doing this.  I also
> strongly agree with
> you that the Twisted experience needs to be positive within the
> first fifteen
> minutes of the download, and it bothers me that the Windows
> installer is not in
> very good shape.  (Have you tried the debian install though?
> It's smooooth
> ^_^)

Unfortunately my various attempts to install Linux have all
failed horribly, usually with graphics drivers and after a lot more
than 15 minutes :-).  I still use Windows on my desktop.  We use
FreeBSD on our servers and Solaris at most customer sites, but only
'as servers'. My Linux knowledge is bound to be worse that yours of
Windows :-)

> Well, if your testers are sysadmins they tend to be irritated by the
> installation problems a lot more often.  Trouble is that sysadmins rarely
> install server frameworks on their own...

I have two "junior programmers" who will probably be ideal.
John knows Python, Dragan knows Java and a little Python, but they
(like me) are new to networking.  John is also our docco expert.
I suggest holding off until we "think it's sorted" and using
them for first impressions on the install process and examples.
You can only use each tester once for this kind of thing.

The other one, Robin becker, will no doubt ignore all docco, read the
source and maybe even any binaries, then discover something nasty
lurking in your innermost Windows event loops ;-)


Thanks,

Andy