prompt: You will be provided with a partial code base and an issue statement explaining a problem to resolve.
  <issue>
  Clean up `update-locked-requirements` and `requirements.in` files to remove `-e` hackery.
  It looks like https://github.com/jazzband/pip-tools/pull/807 was included in the latest `pip-tools` release 12 days ago.  I think this may mean we can get rid of our semantically incorrect usage of `-e` in our requirements files, which in turn may mean we can remove most of the messy code in `tools/update-locked-requirements` related to hackily removing the `-e` lines. 
   See `compile_requirements` in that file for details.  
  
  My guess is that this means if we upgrade pip-tools, we can delete 50% of the code in `update-locked-requirements` and clean up our `requirements.in` files to not use `-e`.  
  
  @hackerkid this might be a good project for you.
  Clean up `update-locked-requirements` and `requirements.in` files to remove `-e` hackery.
  It looks like https://github.com/jazzband/pip-tools/pull/807 was included in the latest `pip-tools` release 12 days ago.  I think this may mean we can get rid of our semantically incorrect usage of `-e` in our requirements files, which in turn may mean we can remove most of the messy code in `tools/update-locked-requirements` related to hackily removing the `-e` lines. 
   See `compile_requirements` in that file for details.  
  
  My guess is that this means if we upgrade pip-tools, we can delete 50% of the code in `update-locked-requirements` and clean up our `requirements.in` files to not use `-e`.  
  
  @hackerkid this might be a good project for you.
  
  </issue>
  <code>
  [start of version.py]
  1 import os
  2 
  3 ZULIP_VERSION = "2.0.4+git"
  4 # Add information on number of commits and commit hash to version, if available
  5 zulip_git_version_file = os.path.join(os.path.dirname(os.path.abspath(__file__)), 'zulip-git-version')
  6 if os.path.exists(zulip_git_version_file):
  7     with open(zulip_git_version_file) as f:
  8         version = f.read().strip()
  9         if version:
  10             ZULIP_VERSION = version
  11 
  12 LATEST_MAJOR_VERSION = "2.0"
  13 LATEST_RELEASE_VERSION = "2.0.4"
  14 LATEST_RELEASE_ANNOUNCEMENT = "https://blog.zulip.org/2019/03/01/zulip-2-0-released/"
  15 
  16 # Bump the minor PROVISION_VERSION to indicate that folks should provision
  17 # only when going from an old version of the code to a newer version. Bump
  18 # the major version to indicate that folks should provision in both
  19 # directions.
  20 
  21 # Typically,
  22 # * adding a dependency only requires a minor version bump;
  23 # * removing a dependency requires a major version bump;
  24 # * upgrading a dependency requires a major version bump, unless the
  25 #   upgraded dependency is backwards compatible with all of our
  26 #   historical commits sharing the same major version, in which case a
  27 #   minor version bump suffices.
  28 
  29 PROVISION_VERSION = '49.1'
  30
  [end of version.py]
  </code>
  
  I need you to solve this issue by generating a single patch file that I can apply directly to this repository using git apply. Please respond with a single patch file in the following format.
  <patch>
  diff --git a/file.py b/file.py
  --- a/file.py
  +++ b/file.py
  @@ -1,27 +1,35 @@
   def euclidean(a, b):
  -    while b:
  -        a, b = b, a % b
  -    return a
  +    if b == 0:
  +        return a
  +    return euclidean(b, a % b)
   
   
   def bresenham(x0, y0, x1, y1):
       points = []
       dx = abs(x1 - x0)
       dy = abs(y1 - y0)
  -    sx = 1 if x0 < x1 else -1
  -    sy = 1 if y0 < y1 else -1
  -    err = dx - dy
  +    x, y = x0, y0
  +    sx = -1 if x0 > x1 else 1
  +    sy = -1 if y0 > y1 else 1
   
  -    while True:
  -        points.append((x0, y0))
  -        if x0 == x1 and y0 == y1:
  -            break
  -        e2 = 2 * err
  -        if e2 > -dy:
  -            err -= dy
  -            x0 += sx
  -        if e2 < dx:
  -            err += dx
  -            y0 += sy
  +    if dx > dy:
  +        err = dx / 2.0
  +        while x != x1:
  +            points.append((x, y))
  +            err -= dy
  +            if err < 0:
  +                y += sy
  +                err += dx
  +            x += sx
  +    else:
  +        err = dy / 2.0
  +        while y != y1:
  +            points.append((x, y))
  +            err -= dx
  +            if err < 0:
  +                x += sx
  +                err += dy
  +            y += sy
  +
  +    points.append((x, y))
       return points
  
  </patch>
golden_diff: diff --git a/version.py b/version.py
  --- a/version.py
  +++ b/version.py
  @@ -26,4 +26,4 @@
   #   historical commits sharing the same major version, in which case a
   #   minor version bump suffices.
   
  -PROVISION_VERSION = '49.1'
  +PROVISION_VERSION = '49.2'
  
verification_info: {"golden_diff": "diff --git a/version.py b/version.py\n--- a/version.py\n+++ b/version.py\n@@ -26,4 +26,4 @@\n #   historical commits sharing the same major version, in which case a\n #   minor version bump suffices.\n \n-PROVISION_VERSION = '49.1'\n+PROVISION_VERSION = '49.2'\n", "issue": "Clean up `update-locked-requirements` and `requirements.in` files to remove `-e` hackery.\nIt looks like https://github.com/jazzband/pip-tools/pull/807 was included in the latest `pip-tools` release 12 days ago.  I think this may mean we can get rid of our semantically incorrect usage of `-e` in our requirements files, which in turn may mean we can remove most of the messy code in `tools/update-locked-requirements` related to hackily removing the `-e` lines. \r\n See `compile_requirements` in that file for details.  \r\n\r\nMy guess is that this means if we upgrade pip-tools, we can delete 50% of the code in `update-locked-requirements` and clean up our `requirements.in` files to not use `-e`.  \r\n\r\n@hackerkid this might be a good project for you.\nClean up `update-locked-requirements` and `requirements.in` files to remove `-e` hackery.\nIt looks like https://github.com/jazzband/pip-tools/pull/807 was included in the latest `pip-tools` release 12 days ago.  I think this may mean we can get rid of our semantically incorrect usage of `-e` in our requirements files, which in turn may mean we can remove most of the messy code in `tools/update-locked-requirements` related to hackily removing the `-e` lines. \r\n See `compile_requirements` in that file for details.  \r\n\r\nMy guess is that this means if we upgrade pip-tools, we can delete 50% of the code in `update-locked-requirements` and clean up our `requirements.in` files to not use `-e`.  \r\n\r\n@hackerkid this might be a good project for you.\n", "before_files": [{"content": "import os\n\nZULIP_VERSION = \"2.0.4+git\"\n# Add information on number of commits and commit hash to version, if available\nzulip_git_version_file = os.path.join(os.path.dirname(os.path.abspath(__file__)), 'zulip-git-version')\nif os.path.exists(zulip_git_version_file):\n    with open(zulip_git_version_file) as f:\n        version = f.read().strip()\n        if version:\n            ZULIP_VERSION = version\n\nLATEST_MAJOR_VERSION = \"2.0\"\nLATEST_RELEASE_VERSION = \"2.0.4\"\nLATEST_RELEASE_ANNOUNCEMENT = \"https://blog.zulip.org/2019/03/01/zulip-2-0-released/\"\n\n# Bump the minor PROVISION_VERSION to indicate that folks should provision\n# only when going from an old version of the code to a newer version. Bump\n# the major version to indicate that folks should provision in both\n# directions.\n\n# Typically,\n# * adding a dependency only requires a minor version bump;\n# * removing a dependency requires a major version bump;\n# * upgrading a dependency requires a major version bump, unless the\n#   upgraded dependency is backwards compatible with all of our\n#   historical commits sharing the same major version, in which case a\n#   minor version bump suffices.\n\nPROVISION_VERSION = '49.1'\n", "path": "version.py"}]}