You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
install --update does not update all runtimes #329
Describe the bug
The documentation states that "Passing --update will replace existing installs if the new version is newer. Otherwise, they will be left. If no tags are provided with --update, all installs managed by the Python install manager will be updated if newer versions are available."
However, when I have multiple runtimes installed and run py install --update only a single version is updated. To update the other versions I must specify the tag explicitly. Note that if I install both 3.13.12 and 3.14.3 (rather than 3.14.4 which is current as of this report), then try to update, neither version is updated.
See attached screenshots.
To Reproduce
Steps to reproduce the behavior:
Install an older patch version of python 3.14 and 3.13
Run py install --update
Only python 3.14 is updated
Run py list to verify that only 3.14 is updated
Expected behavior
All installed runtimes should be updated per the documentation
Additional context
If you have log files (check your %TEMP% directory!), drag-and-drop them here to include them.
One other note. I was surprised that 3.14.4 was updated to 3.14.5.rc1. I wouldn't expect it to update to an RC version without some additional flag. Note that this behavior is different than when I explicitly specify the tags to update. When I specify the tags for 3.13 and 3.14, both versions are updated and it updates to 3.14.4 rather than the RC. See screenshot.
Hmm, updating to the RC was indeed unexpected, but we so rarely do RC's for bugfix releases that it's not too surprising the scenario was missed.
I can't reproduce the other issue, though. Are you able to share the log file from when it doesn't update? Or try with -vv added to the command to print all the logging output to the console?
Here are the relevant logs. I included logs that show update behavior when I specify tags explicitly and those when I don't. Included both an older log and one from today when I updated to 3.14.5
Ah, that helps. The problem is that it first searches the exact index that the package was originally installed from, and we use a three-tiered feed on python.org to minimise downloads. The 3.14.3 install came from the second part of the index, and so when it went looking for an update it started searching from that file rather than the first one.
When you specify a tag, we don't use the existing URLs but search fresh (expecting that you'll also specify your own index if you're using one), which is why it finds the later version.
To fix it, we need to make sure that we store the URL originally provided by the user (or the default) with the package, rather than the URL of the index file that actually contained it.
Activity
scorgatelli commentedon May 5, 2026
One other note. I was surprised that 3.14.4 was updated to 3.14.5.rc1. I wouldn't expect it to update to an RC version without some additional flag. Note that this behavior is different than when I explicitly specify the tags to update. When I specify the tags for 3.13 and 3.14, both versions are updated and it updates to 3.14.4 rather than the RC. See screenshot.
zooba commentedon May 5, 2026
Hmm, updating to the RC was indeed unexpected, but we so rarely do RC's for bugfix releases that it's not too surprising the scenario was missed.
I can't reproduce the other issue, though. Are you able to share the log file from when it doesn't update? Or try with
-vvadded to the command to print all the logging output to the console?zooba commentedon May 12, 2026
#332 is now the issue for updating to RC (not that it is likely to happen again).
If there's no further information available on the update failures, we'll have to close this one.
scorgatelli commentedon May 12, 2026
Here are the relevant logs. I included logs that show update behavior when I specify tags explicitly and those when I don't. Included both an older log and one from today when I updated to 3.14.5
python_install_20260512104744_43652_no_tags_specified_3144to3145.log
python_install_20260505114211_22600_tags_specified.log
python_install_20260505113339_12840_no_tags_specified.log
zooba commentedon May 12, 2026
Ah, that helps. The problem is that it first searches the exact index that the package was originally installed from, and we use a three-tiered feed on python.org to minimise downloads. The 3.14.3 install came from the second part of the index, and so when it went looking for an update it started searching from that file rather than the first one.
When you specify a tag, we don't use the existing URLs but search fresh (expecting that you'll also specify your own index if you're using one), which is why it finds the later version.
To fix it, we need to make sure that we store the URL originally provided by the user (or the default) with the package, rather than the URL of the index file that actually contained it.
Store requested source URL with install rather than eventual. (#340)