This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Add a ProviderKey to the installer bundle
Type: behavior Stage: resolved
Components: Windows Versions: Python 3.7, Python 3.6, Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: steve.dower Nosy List: ned.deily, paul.moore, python-dev, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2016-11-30 23:57 by steve.dower, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (4)
msg282118 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-11-30 23:57
Currently the installer bundles for 3.5 and later have an automatically generated dependency provider key. This makes it difficult for other installers to correctly depend on the bundle.

For example, Visual Studio 2017 has an option to install CPython 3.5, but it cannot accurately determine when it is already installed, which may lead to Python being uninstalled unexpectedly. This is the purpose of the provider key - to provide a reliable key by which to reference the bundle.

For 3.5.2 and earlier, the key is a GUID that changes each release, but really the key should be stable for each version that cannot be installed side-by-side.

The change is to Tools/msi/bundle/bundle.wxs and adds the last attribute to this element:

  <Bundle Name="!(loc.FullProductName)"
          UpgradeCode="$(var.CoreUpgradeCode)"
          Version="$(var.Version)"
          IconSourceFile="bundle.ico"
          Manufacturer="!(loc.Manufacturer)"
          AboutUrl="http://www.python.org/"
          DisableModify="button"
          Compressed="no"
          dep:ProviderKey="CPython-$(var.MajorVersionNumber).$(var.MinorVersionNumber)$(var.PyArchExt)$(var.PyTestExt)">

This will produce keys like "CPython-3.5", "CPython-3.5-32", "CPython-3.5-test" and "CPython-3.5-32-test" (the "-test" suffixed installers are never released, but may be produced by Tools/msi/build.bat).

I haven't tested it yet, but I believe this change will also fix a minor issue where the web and non-web installers conflict, even when the versions match.

Since it is important this metadata be consistent throughout the lifetime of a release, I'd like to get the change into Python 3.6.0rc1 after I've spent the time testing it. Ned - your thoughts?
msg282127 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2016-12-01 02:17
Sounds good to me.
msg282302 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-12-03 20:13
New changeset 68530c0a1487 by Steve Dower in branch '3.5':
Issue #28846: Various installer fixes
https://hg.python.org/cpython/rev/68530c0a1487

New changeset 5171bd86a36f by Steve Dower in branch '3.6':
Issue #28846: Various installer fixes
https://hg.python.org/cpython/rev/5171bd86a36f

New changeset 014f52fe1da1 by Steve Dower in branch 'default':
Issue #28846: Various installer fixes
https://hg.python.org/cpython/rev/014f52fe1da1
msg282303 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2016-12-03 20:15
This bloated into a couple of extra build/installer fixes, including *finally* fixing the sys._mercurial bug (I hope). I can also now merge fairly cleanly between 3.5 and 3.6 again, so I'm happy for a while :)
History
Date User Action Args
2022-04-11 14:58:40adminsetgithub: 73032
2016-12-03 20:15:04steve.dowersetstatus: open -> closed
resolution: fixed
messages: + msg282303

stage: needs patch -> resolved
2016-12-03 20:13:14python-devsetnosy: + python-dev
messages: + msg282302
2016-12-01 02:17:25ned.deilysetmessages: + msg282127
2016-11-30 23:57:38steve.dowercreate