I've wanted bdist_msi to work for ages. There was some issue with the install scripts that always caused grief, and my memory is hazy - it *might* be that the uninstall process doesn't run the post-install script at the correct time - ie, that it runs *after* the uninstall, which means pywin32 isn't available to undo some of the stuff it did as it can't import pywin32 itself. Another problem I'd expect to find is that the post-install script tries to tell distutils about new files and registry entries created at install time - this probably fails silently now (ie, it might *appear* to work but probably leaves trash behind.)
That said, if we can make it work correctly in these cases, I'm definitely up for accepting patches! As to some of your other points: On 20/06/2013 7:51 AM, Will Sadkin wrote:
I really need to be able to do a silent install of the pywin32 package for python2.7,
The other way to approach this is simply to copy the files yourself and run the post-install script manually - ie, I assume you want to install pywin32 as part of a "larger" install, so you could just ignore the pywin32 installer completely...
1) I couldn't build from the latest source version (218). This is because the downloadable pywin32-218.zip file is either incomplete or inconsistent, because the win32\src\PerfMon directory no longer includes perfutil.h, but the code therein attempts to include it. (See bug https://sourceforge.net/p/pywin32/bugs/647/.)
Yeah, I screwed that release up in that regard. I normally unzip the source package and attempt to build it before release, but forgot that time :(
(That is, exclude the .0 from the string, so that it was just '2.7.217'. This seemed a reasonable thing to do, as I've never seen a "patch" number on any pywin32 version, and the rest seemed appropriate, but I don't know if Mark Hammond would agree, and if there ever was a patch number, this would not work.)
I have used the patch version in the past - mainly when I've found one single package was uploaded incorrectly due to a build issue rather than due to a bug in the code itself.
eg: https://sourceforge.net/projects/pywin32/files/pywin32/Build216/ - where is a "216.1" build for Python 3.2.
The other thing I've done in the past is to upload custom pywin32 builds for people when they've reported a bug but can't rebuild the world to test it - I usually change that version string immediately after release, so any such "interim" builds can't be confused with the official builds (but such builds don't end up on sourceforge)
But I'm happy to change things in this area if it blocks support for MSI. The other thing I'd want to make sure is that the Python version in that number does something sane - eg, I wouldn't want the MSI infrastructure to think that "2.7.217" was an earlier version (or even related in any way) than "3.2.216" etc.
It turns out that this distutils bug was reported back in August of 2012, and a patch has even been supplied (see http://bugs.python.org/issue15797.) When I applied the supplied patch, and rebuilt my msi, it properly ran the postinstall script, and (as far as I can tell) the resulting install works perfectly!
I can probably help push that through. Although it seems unlikely for it to be accepted into the 2.x branch, which is a problem. OTOH though, if you help get this working and you only care about 3.x, I could certainly live with the fact that MSI installers are only available for 3.x...
I wonder if there are heuristics the post-install script could use to work around this itself? You said the uninstall worked - did it actually leave a clean file-system afterwards? If so, it would seem the issue I mentioned before might not be a problem at all - but it's not clear to me how, even if pywin32 was fully unavailable at uninstall time, how we could determine if this invocation is for a re-install or an uninstall (ie, it's not clear to me that the absence of certain files would be a reliable guide here)
(And there was much rejoicing... yea...)
Awesome :)
So: The reasons for my post to this forum: 1) Is the change I made to the version string used in the dist construction appropriate? If not, what would be the appropriate version to use?
We can work something out there.
2) Can this version be used for both the .exe and the .msi build methods, or, if not, is there a way to conditionally set this based on which type of build is being attempted?
Not having a patch version for the .exe distros would be fine even if it means I need to change a couple of things in how I release.
3) The patch for distutils was submitted in August of 2012, but, AFAICT, has not been incorporated into the 2.7.x distutils source; is there a way to expedite that?
I can probably help, but as mentioned, I'm not sure it would be acceptable for 2.x. Getting it only in 3.latest would mean I can probably get things to work for all 3.* builds - but not 2.* builds.
4) Would it be possible to take all of this into account, verify that I'm not missing anything subtle, and generate "official" .msi files for pywin32, since this is all targeted *for Microsoft systems,* after all... ;)
Sure - although TBH my personal motivation for this is quite small (I'm not using Python at all in my day-job) and my time is pretty tight at the moment (and I'm away for the next week or so, so will be slower than usual in replies etc) - so the reality is that you are probably going to need to drive this - with my support - to make it happen.
Cheers, Mark _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
