[python-win32] Building pywin32 msi installers

[Mark Hammond]

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