code: def _avoid_setuptools_zipped_egg_upgrade_issue(env, ez_setup):
      
      if env.sys_version_info[:2] != (2, 5):
          return  # only Python 2.5.x affected by this
      if not env.setuptools_zipped_egg:
          return  # setuptools not pre-installed as a zipped egg
      pv_new = parse_version(ez_setup.setuptools_version())
      if pv_new != parse_version(env.setuptools_version):
          return  # issue avoided since zipped egg archive names will not match
      fixed_version = utility.lowest_version_string_with_prefix("3.5.2")
      if pv_new >= parse_version(fixed_version):
          return  # issue fixed in setuptools
      # We could check for pip and use it for a cleaner setuptools uninstall if
      # available, but YAGNI since only Python 2.5.x environments are affected by
      # the zipped egg upgrade issue.
      os.remove(env.setuptools_zipped_egg)
docs: Avoid the setuptools self-upgrade issue.
  
      setuptools versions prior to version 3.5.2 have a bug that can cause their
      upgrade installations to fail when installing a new zipped egg distribution
      over an existing zipped egg setuptools distribution with the same name.
  
      The following Python versions are not affected by this issue:
        Python 2.4 - use setuptools 1.4.2 - installs itself as a non-zipped egg
        Python 2.6+ - use setuptools versions not affected by this issue
      That just leaves Python versions 2.5.x to worry about.
  
      This problem occurs because of an internal stale cache issue causing the
      upgrade to read data from the new zip archive at a location calculated
      based on the original zip archive's content, effectively causing such read
      operations to either succeed (if read content had not changed its
      location), fail with a 'bad local header' exception or even fail silently
      and return incorrect data.
  
      To avoid the issue, we explicitly uninstall the previously installed
      setuptools distribution before installing its new version.