Python 2.4 killing commercial Windows Python development ?

[Steve Holden]

Jimmy Retzlaff wrote:
> Terry Reedy wrote:
> 
>>I guess I don't understand some people's determination to not have users 
>>install fully useable Python on their Windows machines.  Doing so seems no
>>different to me than having to install (or upgrade) Shockwave, or Apple's
>>Quicksomething for Windows (not used so much anymore), or RealPlayer,
[yada yada yada]
>>I left out the most direct analogy of a java system.)
> 
> 
> The Windows application that I develop and distribute relies on Python
> plus 14 other packages (wxPython, pywin32all, ctypes, Numeric, PIL,
> etc.). My customers typically install the application on 20-100 user
> machines within their organization at one time so it's mandatory that I
> make an automated silent installer available. That's a lot easier to do
> with py2exe and a Windows installer than it is to do with Python's MSI
> and 14 other packages. It's also more robust - the installer is much
> simpler and my application is always used with exactly the same Python
> environment that was used for QA.
> 
Given the choice between twelve time twenty-five megabytes of solid, 
reliable Python with no detectable version inconsistencies and a lean, 
mean, sharing, caring 25-program package at fifty megabytes total any 
sensible user would jump at the former. Disk is now below a dollar a 
gigabyte and you are right, people should get over it. Small may be 
beautiful, but for a bunch of related but independent modules, 
maintaining the system can lead to inconvenient version lock-step. The 
monolithically-installed program is a black box that stands alone.

> There are also significant hurdles to clear before software can be put
> on user machines in an organization like this. The reviews with the IT
> groups go much more smoothly since I can state that my installer will
> only write files to one folder of the IT group's choosing, put an icon
> in the Start Menu, and will only touch the registry to register an
> uninstaller. If there were 15 installers being run (even if automated)
> we'd have to review each of those individually and my product would
> almost never be approved.
> 
The refuseniks would probably be justified, too.

> I don't actively hide the fact that I use Python, but my customers are
> rarely interested in my toolbox - they are too focused on their own
> business. Some groups will ask what language I use, and the following
> question will always be something like "If we need it to, can it
> interact with Java?" or C# or ...  that's their only interest in the
> language I use. If they open themselves up by asking then I can't help
> but badger them with the virtues of Python for a while. :)
> 
> 
>>To put it another way, needing a Python interpreter to run .py files
> 
> is no
> 
>>different from, for instance, needing a movie player to run .mpg
> 
> files,
> 
>>and all Windows users are or need to become familiar with that general
>>concept.
> 
> 
> Many of my users don't have a concept of a "file" unless it's something
> they ask their assistant to get from a cabinet. They are typically
> corporate executives for very big companies and if they have a computer
> problem then a team of IT people get paged to fix it immediately. They
> don't "need" to become familiar with anything on a computer - their job
> is managing many billions of dollars worth of business every year. They
> can use almost every feature of my application if they can move the
> mouse and click the left button. That requires training for some of
> them, and I feel honored they'll take the time to learn that much in
> order to use my software.
> 
Now that's an approach that sounds crafted to ensure pride in one's work 
and job satisfaction. It's also correctly mindful of the computer's 
peripheral role in most decision-making and recording processes.
> 
>>Also, I think it a bit 'anti-social' to hide usage of Python.  If all
>>Python Windows programs ran with a normal, communally installed
>> Python,
>>then users would gradually get the idea that having Python installed
>> is 
>>much like having Shockwave and other utility platforms installed, and
> that
>>is is part of a 'fully loaded' Windows system to have a .py player
>>installed.
> 
> 
> I feel the opposite. I've skipped evaluating a number of applications
> because they didn't come with their own dedicated JVM. I've spent way
> too much of my own time trying to use applications with conflicting JVM
> requirements only to give up in the end. It's just a new form of DLL
> hell.
> 
I'm with you. This is a pragmatic engineering approach to operating 
large numbers of systems with minimum hassle.

> As a user, I only want to think about how well an application does what
> I need it to do. The more time I spend dealing with supporting
> technologies, the less time I spend on the intended task.
> 
> 
>>If there is something about the default install of Python on Windows
> that 
>>makes it less desireable or less easy than other platforms, then maybe
>>that can be fixed.
> 
> 
> Something like Flash is quite special purposed and you don't have tons
> of large extension modules that are in common use. You just use the base
> system and it is very tightly controlled by one organization to maintain
> backwards compatibility. And it is primarily used to augment/replace
> HTML pages, so you don't want to download/install the engine each time
> you come across another page with Flash content. Applications are
> different, you acquire them once and use them over and over and the
> runtime environment is much more variable from app to app. You don't
> just have to worry about the backward compatibility of Python itself,
> but of every extension module in common use and all the combinations
> that arise out of that. Again look at the pain of shared JVM use. I
> think Microsoft is on the right track to addressing DLL hell now by
> recommending that DLLs be installed in the application folder, not the
> system folder. That's analogous to using application specific JVMs and
> things like py2exe or cx_freeze for Python.
> 
> 
>>To make installation easier, maybe someone could write a
>>small .exe that could be frozen with scripts or run with installers
> and 
>>that would detect the presence/absence of the needed Python version
>> and 
>>offer an auto download and install if needed.
> 
> 
> My users only get access to "approved" sites (nothing else shows up in
> their DNS). It's hard enough to get my own domain added to the ordained
> list, much less a long list like python.org, sourceforge.net,
> effbot.org, etc.
> 
Yup. Single point of responsibility is usually also appreciated, given 
the finger-pointing that can occur.

> All this isn't just for my clients. I have a number of automated
> processes that I run on my server that are written in Python. When I
> need a new version of some module for one of those processes, I don't
> want to spend the time testing it with each of the others to make sure
> it didn't break anything. So I build single file executables from my
> Python scripts so they are completely self-contained. When I want to
> modify a module, then I can test/correct the impact of any new modules
> at that point since I'll be in the code anyway. Before I started doing
> this, the version of Python and the various extension modules in use on
> my server was a couple of years older than the version on my development
> machine because I almost never upgraded for fear of breaking several
> processes.
> 
Way hay! A sound engineering approach pays off. Who would have thought?

> Hard drive space is cheap and building exes is easy and I like the
> benefits.
> 
> Jimmy
> 
> p.s. - on the original topic of this thread - I also buy development
> tools from Microsoft that ensure I have the right to distribute the
> needed DLLs so it's not a concern in my case.

Jimmy:

Thanks for injecting the voice of experience into this debate. Your use 
cases certainly aren't vaporous.

regards
  Steve
-- 
Steve Holden        +1 703 861 4237  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/