PC/python_nt.rc sets up the DLL version resource (displayed when you
right-click on the DLL and select Properties).
PCbuld/python20.wse sets up the installer version resource (displayed
when you right-click on the installer .exe and select Properties). Turns
out this one hadn't been updated since 2001 <frown>!
Added the logging package. In the meantime, Neal Norwitz added a
test_logging.py to the std test suite, which would have caught this
oversight in the Windows installer.
whether this is a correct thing to do:
+ There are linker warnings (see PCbuild\readme.txt).
+ test_bsddb passes, in both release and debug builds now.
+ test_bsddb3 has several failures, but it did before too.
Also made pythoncore a dependency of the _bsddb project, updated
build instructions, added database conversion XXX to NEWS, and fiddled
the Windows installer accordingly.
+ News blurb, but as much XXX as news.
+ Updated installer (install the new bsddb package, and the Berkeley DLL;
still don't know how to fold that into _bsddb.pyd).
+ Fleshed out build instructions.
+ Debug Python still blows up.
running IDLE, and since I'm not a Tcl Guy I'm not sure what else to do.
Up to you! See XXX comments in PCbuild\readme.txt for cautions.
Also repaired typos in the new bz2-for-Windows instructions.
option. It was the cause of at least one way UNWISE.EXE could vanish
(install a python; uninstall it; install it again; reboot the machine;
abracadabra the uinstaller is gone).
Bugfix candidate, but I'll backport it myself.
I'm guessing at this, pending more info from the bug submitter. Wise
changed how the %GROUP% vrbl got defined between versions 5.0a (used
before Python 2.2) and 8.14, to hold the full path to Start Menu group
instead of just the group name. If I'm guessing correctly, the info
the bug report is complaining about is in one of the registry keys
we set up that neither Windows nor Python cares about. We did store
a full path there in 2.2b1 instead of just the group name; the patch cuts
it back to just the name again.
not disabled file-extension registration, arrange for .py and .pyw files
to have an "Edit with IDLE" context (right-click) menu entry, selecting
which executes IDLE w/ the -e switch followed by the selected file's path.
IDLE and pydoc into a separate component. That's almost as big as the
rest of Python (excl. docs and test suite) combined.
Pop up a confimation box if they choose to install at least one of
{Tcl/Tk/IDLE/pydoc, Tools, Test suite} but do not choose to install
Python -- doesn't make much sense, so ask whether that's really what they
want.
LettError, Erik van Blokland, http://www.letterror.com/
the Python Windows installer finally has an attractive Pythonic bitmap
to delight the senses and dampen the fears of the millions and millions of
eager new Windows users anticipating their first Python programming joy.
Always knew Mac users secretly wanted to switch to Windows <wink>.
In the Wise installer's "Advanced Options" dialog, substitute in the
actual name of "the system directory" -- this is clearer, and especially
for people reading this dialog who aren't me <wink>.
mistake).
+ Arrange for Win2K Add/Remove to show a Python icon.
I think this "does it" -- a full install/uninstall can now be done on a
Win2K box from an ordinary (not Admin, not Power User) user acct, incl.
file extension registration, Start Menu entries, and full Add/Remove.
been overwriting them even if they have the same version, not just if
they're an older version (and our installers have always done this).
+ Added an "Advanced Options" subdialog to "Select Components". Allows
to do a non-admin install even if you have Administrator rights, and
to skip registering file extensions and/or creating Start Menu
shortcuts. Since so far these installers have been tested only by me,
and Win2K has been full of surprises, I want those options available
out in the field.
Lots of web searching turned up what should have been obvious: Because
Windows Installer is a native Win2K service, it can run at a higher
privilege level than the user invoking it. So MSI installs don't bash
into these permission gotchas on Win2K, but Wise 8.1 does (it's just
another app to Win2K, and we're not alone in wrestling with this; but,
like changing int division in Python, Win2K is doing a right thing <wink>).
Can't test it until getting to a Win2K box, because the non-Admin way
of setting file associations on Win2K doesn't work on any other flavor
of Windows (and other flavors of Windows never need Admin privs to
do it the old way).
+ Consequently got rid of the "Register file associations" Component and
associated GUI.
+ Added a line to the summary saying whether or not this is an Admin-level
install (I fear that will be an important clue someday).
+ Minor fiddling to the summary to reduce the # of lines. Added a
horizontal scrollbar in case the install path is very long.
+ Reworked the way the Main and Tools components share pydoc.pyw; cleaner
and simpler.
and install the Python and MS runtime DLLs into the Python dir instead of
a system dir.
Initial value is taken from new compiler vrbl _DOADMIN_ (default true),
and forced to false if the user doesn't have admin privs.
This makes it possible to *test* non-admin installs on machines where the
distinction doesn't exist (like my home box), via just changing _DOADMIN_.
It may also be useful for users who don't *want* an installer to
scribble into their system dir (for example, me(! most days)), but that
would require adding more GUI to let them get at it.
+ Fiddle vrbls so Win2K add/remove can display version w/o future manual
script fiddling.
+ Break apart the mysterious wizard-generated Win2K "Edit 3 Registry Keys"
script items by hand into 3 separate items, so you can see what the heck
they're doing in the script view.
+ pydoc.pyw was a problem: it's installed by both the Main and Tools
components. So when both were selected, the second time it got
installed Wise figured it was overwriting a pre-existing version, and
made a backup copy in BACKUP. A rollback-uninstall then restored that,
leaving the Tools/Scripts/ directory non-empty, and so Wise couldn't
remove that directory (or any above it). Fixed by installing pydoc.pyw
at most once.
+ Rearranged and commented the "register file extensions" section, because
it was confusing and needs more work: turns out it's not true that
Win2K requires Admin privs to register file extensions, BUT, if you
don't have Admin privs, Win2K requires a new way to register file
extensions, and a way that doesn't blow up but doesn't do any good either
on earlier Windows flavors. I think I know how to get this done, but am
too depressed to do it right now <0.7 wink>.
+ Ditto pydoc.
(IMO, both should have been done long ago -- simply didn't occur to
me before)
+ Build the summary text into a vrbl instead of a temp file. Doh! Less
fiddling, and should avoid another class of Win2K permission problems.
Bug: the "auto vertical scrollbar" control on the summary page doesn't
work (never creates a scrollbar, no matter how much text). So forced a
vertical scrollbar there.
summary of the preceding choices. No idea if this is "the right way" to
do it, but it's exactly painful enough to make me suspect it's the only
way <wink>.
delete the Tools and Lib directories at uninstall time. However,
under the old version of Wise, they didn't actually do anything. Under
the new version, they work as advertised, and even delete files users
added.
Got rid of those, and replaced them with similar uninstall cmds that
get rid of all .pyc and .pyo files (whether or not the installer created
them). This works nicely! It still tears down the directory structure,
except for those directories needed to get to any non-.pyc/o file(s) the
user may have added.
Tim Peters
Mark Hammond