On 23 May 2000, Thomas Heller said:
OK, will submit an 'bdist_wise' sometime. Or maybe 'bdist_wisescript' because it will create an xxx.wse script, which has to be compiled with Wise32.exe.
Great! A bit of calibration: "bdist_rpm" exists mainly to create the .spec file, but at the end of the job it runs "rpm -b..." for your convenience. It has --spec-only, --source-only, and --binary-only options for finer control. I think "bdist_wise" should do roughly the same: create the .wse file, and then (optionally, but by default) compile it with Wise32.exe.
Whether you want to embed Python really depends on your audience. Let's face it, installing Python on Windows is not that hard. If a programmer wants to use some collection of modules, it's not too bad to say, "Download and install Python, then download and install the module distribution". Painless * 2 is not too bad.
Sure. But: Windows users are (normally) not used to the command line (neither will they read the README file :-). They are used to installer executables.
No no, I'm not arguing for a command-line installer. (Except for the hard-code Pythonistas who want to build everything from source, and think the current Distutils interface on Windows is just fine.) I'm arguing that Joe's Handy Python Modules should *just* include joes/module1.py, joes/module2.py, and related files -- ie. pretty much what goes into other Distutils-generated built distributions ("dumb" tarballs or zip files, or "smart" binary RPMs). The boundary between Joe's Handy Python Modules and Jim's Humongous Python-Based Application (which probably should include an embedded Python interpreter and library) is fuzzy -- I'm not sure where eg. NumPy falls. That should be the developer's decision to make.
(Hmmm, now why did the name "Jim" come to mind when thinking of humongous Python-based applications...)
I did not think about end-user applications here. Is distutils headed in this direction after all?
Well, yes, eventually. We have to keep it in mind. Support for "building" and installing scripts is already partly there. (When someone can download Zope and run "python setup.py install", and setup.py is a reasonably normal Distutils-style setup script, then I will hang up my keyboard and go home.)
[I outline my vision]
I think the mode of operation should be as close to the other bdist commands as possible: distribute a pseudo-installation tree and just copy it in place. That is, the setup script shouldn't enter into it here, *unless* you need it to extract package meta-data. (Unless that's put into another file when you run "bdist_wininst".)
[Thomas describes his]
I was more thinking about a zip-selfextractor, extracting the archive into the python installation directory automatically. The GUI is/will be not more than a dialog box displaying some meta-info (name, version,...) of the installed modules. The GUI is written in C. So it is not neccessary to embed python (Maybe for compiling pyc files?)
We're not contradicting each other. By "mode of operation" I was more concerned with how "installers" or "built distributions" or whatever are created, and what's included in them, not how the user uses them. Of *course* on Windows it should be an executable -- that's the local convention. And if a self-extracting zip file is the best way to do it, then do it!
A few questions/comments:
* the default installation directory should obviously be where Python will find it: sys.prefix. So you'll either have to run "python -c 'import sys; print sys.prefix'" or get this information from the registry. I'm guessing the latter is preferable and doable -- as long as you can put arbitrary code into the self-extractor.
* what if there are multiple Python installations -- are they sufficiently differentiated in the registry? Eg. I might have Python 1.5.2 and 1.6a2 installed, and I would have to choose which one to install to. What if it's a question of 1.6a1 vs 1.6a2 -- are Python's registry entries sufficently fine-grained to resolve this?
* should we allow writing to a different directory than the default (sys.prefix)? (This would require writing a .pth file in sys.prefix.) Or is this getting too close to a "real" installer?
* how would the actual installer be created? I'm hoping that the CCompiler abstraction would be good enough -- just create yourself a CCompiler (which could be a MSVCCompiler, BCCompiler, Mingw32CCompiler, ...) object, compile a few things, and link an executable.
* interesting data point/existence proof: the Java installer- generator InstallAnywhere let me create an executable Windows installer *entirely* on my Solaris box -- I think it carries around a "stub" executable, and somehow generates the real executable by munging it with my Java code (and other stuff to install). Needless to say, this is *very* cool; it is also an incredibly fat, slow, and heavyweight product. If you can let me generate Windows installers under Solaris or Linux, I'll buy you *two* beers at the next Python conference. (I already owe you one.) ;-)
More about Wise: Wise is a full fledged windows installer. These programs handle the following and more:
- Check the access rights to install the program and its utilities
- Let the user select an installation directory
- Create shortcuts in the start menu so that the user can start the program
- Care about incrementing the ref-count of shared files (usually dlls)
- Create file associations for program specific data files
- Install accessories needed for the program: database access, device
drivers, system services
- Create registry entries
- Create some meta data for uninstallation and install an uninstaller
- Care about replacing in-use files (common under windows)
Nearly all of this is not needed for python modules and extensions, and if it is, IMO it should be handled by distutils.
Agreed, except for the somewhat mythical Jim's Humongous Python-Based Application -- there, all of these "real installer" problems are undoubtedly a concern. That's not a big concern for Distutils 1.0, though -- unless bdist_wise is really easy, I would focus on bdist_wininst, as it sounds like it would be a lot lighter weight, and not require any additional software other than Python/Distutils.
Wow, this sounds *neat*! And I thought being able to build RPMs was cool (no offense, Harry...)