Hi Steve,

Thanks for a quick reply.

> Yeah, this whole issue is basically because Burn (our installer tool) won't do
> per-machine bundle registration even when it's only installing per-machine
> packages. So the install block that it would normally throw up fails if you
> use a different user account to install it the second time.

Hmmm, I'm not sure this is exactly the case as this seems to happen even when we
install Python using the `systemuser` user account initially and then rerun the
installer using that same user account.

Might I suggest adding this information to some 'known defects/limitations'
Python documentation though? Together with more details on what it implies and
how to deal with it? The current behaviour definitely does not seem like
something one would expect as a user.

> > (Python gets installed as a step in one of our installers)
>
> I'm intrigued by this - if Python is a dependency of your application, it's
> better to repackage it yourself and install to your own directory. The
> installer is basically there for end-users, but if you're not doing an
> end-user kind of install there's really nothing gained.
>
> This whole scenario is fairly under-developed though. It comes up quite
> infrequently, so we don't have any really convenient instructions on how to go
> about it. Doesn't mean we can't help, but because we don't have a clear idea
> of what you may be trying to achieve, we'd like to hear about it before
> telling you how to approach this kind of thing.

Our thinking was that if Python already wrapped up all of its installation logic
to 'work correctly' (clean install, upgrade, uninstall, detecting files already
in use, updating any relevant registry settings or globally installed files,
etc.), we might as well use that, so we run the installer in silent mode and
just process its exit code for stuff like errors, reboot required, etc.
Logically the same process that Microsoft gives as the official way to install
its Visual Studio run-time libraries (not saying that process is not filled with
its own caveats :-D).

We can of course take the installed Python distribution folder content and
package that up in our installer directly, and that would avoid the official
Python installer problems. We were hoping to avoid the problem of manually
updating such a repackaging, e.g. Python deciding to add some more data to the
Windows registry, some add-on installation copes with that and now requires that
information to work correctly as well so now we have to debug/detect that also
and tweak our installer to do the same, deal with any related version updating
logic, etc.

By embedding your installer, our 'Python version upgrade' process basically
becomes:
- pop the new Python installer into our 3rdparty library archive
- update the used Python version configuration
- run the installer build

So if this bad installer behaviour is not going to get fixed, I guess we'll go
and play with getting this working using Python's Windows embeddable zip file
distribution instead.

All suggestions welcome. :-)

Thanks again!

Best regards,
  Jurko Gospodnetić