Re: Python 2.4 killing commercial Windows Python development ?
- From: Steve Holden <steve@xxxxxxxxxxxxx>
- Date: Tue, 12 Apr 2005 21:43:02 -0400
Jimmy Retzlaff wrote:
[yada yada yada]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,
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.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.
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.
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.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
different from, for instance, needing a movie player to run .mpg
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.
I'm with you. This is a pragmatic engineering approach to operating large numbers of systems with minimum hassle.
Also, I think it a bit 'anti-social' to hide usage of Python. If allthat
Python Windows programs ran with a normal, communally installed
then users would gradually get the idea that having Python installed
is much like having Shockwave and other utility platforms installed, andis 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.
Yup. Single point of responsibility is usually also appreciated, given the finger-pointing that can occur.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 Windowsthatmakes 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.
andTo make installation easier, maybe someone could write a small .exe that could be frozen with scripts or run with installersthat 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.
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.
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.
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/
- Prev by Date: Re: [perl-python] Python documentation ***icities (continued)
- Next by Date: permission
- Previous by thread: RE: Python 2.4 killing commercial Windows Python development ?
- Next by thread: Sockets (Dave Brueck)