Jurko Gospodnetić <jurko.gospodne...@gmail.com> added the comment: 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ć ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue41800> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com