Skip to content
  • Ed Morley's avatar
    6bb4afd1
    Always output the Python version used and reason why (#1196) · 6bb4afd1
    Ed Morley authored
    Previously the Python version used for the build was only output to the
    log if Python was being installed for the first time, or if the cache
    had been invalidated due to stack/Python version/dependency changes.
    
    This meant in the majority of app builds, the Python version was not
    shown. This makes debugging harder, as well as the "your Python
    version is out of date" warnings less useful, since they don't actually
    say what the current version is.
    
    In addition, the reason a Python version was chosen was not explained,
    which could be particularly confusing given the "sticky"/cached version
    behaviour.
    
    For example, if an existing app that doesn't specify a Python version is
    upgraded to a newer stack, the build can fail with a "runtime not available"
    error, but no indication as to why that version was chosen. eg:
    https://heroku.support/955565
    https://heroku.support/958240
    
    Now, the Python version chosen and the reason for that choice is always
    output to the build log.
    
    This is becoming particularly relevant given many apps are upgrading to
    Heroku-20, which being a newer stack, doesn't have all of the older
    runtime versions.
    
    Closes GUS-W-8065925.
    6bb4afd1
    Always output the Python version used and reason why (#1196)
    Ed Morley authored
    Previously the Python version used for the build was only output to the
    log if Python was being installed for the first time, or if the cache
    had been invalidated due to stack/Python version/dependency changes.
    
    This meant in the majority of app builds, the Python version was not
    shown. This makes debugging harder, as well as the "your Python
    version is out of date" warnings less useful, since they don't actually
    say what the current version is.
    
    In addition, the reason a Python version was chosen was not explained,
    which could be particularly confusing given the "sticky"/cached version
    behaviour.
    
    For example, if an existing app that doesn't specify a Python version is
    upgraded to a newer stack, the build can fail with a "runtime not available"
    error, but no indication as to why that version was chosen. eg:
    https://heroku.support/955565
    https://heroku.support/958240
    
    Now, the Python version chosen and the reason for that choice is always
    output to the build log.
    
    This is becoming particularly relevant given many apps are upgrading to
    Heroku-20, which being a newer stack, doesn't have all of the older
    runtime versions.
    
    Closes GUS-W-8065925.
Loading