internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: spack/spack

Issue:
checksum error: cmake 3.15.1
### Steps to reproduce the issue

```console
$ spack install cmake@3.15.1
...
==> Fetching https://github.com/Kitware/CMake/releases/download/v3.15.1/cmake-3.15.1.tar.gz
######################################################################## 100.0%
==> Error: ChecksumError: sha256 checksum failed for /tmp/bioinfo-cimr-worker-dir/workspace/bfx_spacktree_develop/spack/var/spack/stage/cmake-3.15.1-trzwd2ffmsdutngsfatb7atdjketg2o6/cmake-3.15.1.tar.gz
    Expected cdee72c5ef934c4972f1ad4e9c35712589345f3470a3cf15f7be493c170cc965 but got 18dec548d8f8b04d53c60f9cedcebaa6762f8425339d1e2c889c383d3ccdd7f7
```

### Additional information

The CMake repo has a SHA256 txt file that also says it should be `18dec548d8f8b04d53c60f9cedcebaa6762f8425339d1e2c889c383d3ccdd7f7`:
https://github.com/Kitware/CMake/releases/download/v3.15.1/cmake-3.15.1-SHA-256.txt


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/cmake/package.py b/var/spack/repos/builtin/packages/cmake/package.py
--- a/var/spack/repos/builtin/packages/cmake/package.py
+++ b/var/spack/repos/builtin/packages/cmake/package.py
@@ -13,7 +13,7 @@ class Cmake(Package):
     url      = 'https://github.com/Kitware/CMake/releases/download/v3.13.0/cmake-3.13.0.tar.gz'
     maintainers = ['chuckatkins']
 
-    version('3.15.1', sha256='cdee72c5ef934c4972f1ad4e9c35712589345f3470a3cf15f7be493c170cc965')
+    version('3.15.1', sha256='18dec548d8f8b04d53c60f9cedcebaa6762f8425339d1e2c889c383d3ccdd7f7')
     version('3.15.0', sha256='0678d74a45832cacaea053d85a5685f3ed8352475e6ddf9fcb742ffca00199b5')
     version('3.14.5', sha256='505ae49ebe3c63c595fa5f814975d8b72848447ee13b6613b0f8b96ebda18c06')
     version('3.14.4', sha256='00b4dc9b0066079d10f16eed32ec592963a44e7967371d2f5077fd1670ff36d9')


Test patch:
Repository: spack/spack

Issue:
spack module (tcl|lcov|dotkit) loads: does not work with upstream packages
`spack module * loads` does not work with upstream packages.

### Steps to reproduce the issue

```console
$ spack module <module-type> loads <package_in_upstream>
```

### Error Message

```console
==> Error: 'module' object has no attribute 'upstream_module'
```

### Information on your system

I configured `upstreams.yaml` like this

```yaml
upstreams:
  myupstream:
    install_tree: <UPSTREAM_SPACK_ROOT>/opt/spack
    modules:
      tcl: <UPSTREAM_SPACK_ROOT>/share/spack/modules
```
fixes spack module loads for upstream packages
Fixes #12062

It seems that a non-existing function was used. I replaced it with the one used also by the `find` sub-command.

@scheibelp, it seems that last change to this section was from you, I tried tracking if this function was existing before, but with no luck. I mentioned you just because you may be able to check quickly if this is the right fix.


Discussion:
I won't be able to look at this until 7/29.

To check: did you run `spack module <type> refresh` in the upstream instance after doing the install as mentioned in https://spack.readthedocs.io/en/latest/chain.html?highlight=upstream#using-modules-for-upstream-packages?


Resolving patch:
diff --git a/lib/spack/spack/cmd/modules/__init__.py b/lib/spack/spack/cmd/modules/__init__.py
--- a/lib/spack/spack/cmd/modules/__init__.py
+++ b/lib/spack/spack/cmd/modules/__init__.py
@@ -130,15 +130,9 @@ def loads(module_type, specs, args, out=sys.stdout):
                  if not (item in seen or seen_add(item))]
             )
 
-    module_cls = spack.modules.module_types[module_type]
-    modules = list()
-    for spec in specs:
-        if os.path.exists(module_cls(spec).layout.filename):
-            modules.append((spec, module_cls(spec).layout.use_name))
-        elif spec.package.installed_upstream:
-            tty.debug("Using upstream module for {0}".format(spec))
-            module = spack.modules.common.upstream_module(spec, module_type)
-            modules.append((spec, module.use_name))
+    modules = list(
+        (spec, spack.modules.common.get_module(module_type, spec, False))
+        for spec in specs)
 
     module_commands = {
         'tcl': 'module load ',


Test patch:
Repository: spack/spack

Issue:
Magma tcl module refresh error
The refresh of the TCL module for magma does not work.



### Steps to reproduce the issue

```console
$ spack module tcl refresh magma
```

### Error Message
spack/lib/spack/spack/modules/common.py:772 ==> [2019-07-31-16:09:02.077425]   WRITE: magma@2.5.1-alpha1%intel@19.0.4 build_type=RelWithDebInfo +fortran+shared arch=linux-rhel7-x86_64/utjhipx [/xxx/modulefiles/linux-rhel7-x86_64/magma/2.5.1-alpha1/intel-19.0.4-cuda]
spack/lib/spack/spack/cmd/modules/__init__.py:283 ==> [2019-07-31-16:09:02.098188] NameError: global name 'prefix' is not defined
spack/lib/spack/spack/cmd/modules/__init__.py:285 ==> [2019-07-31-16:09:02.101102] Warning: Could not write module file [/xxx/modulefiles/linux-rhel7-x86_64/magma/2.5.1-alpha1/intel-19.0.4-cuda]
spack/lib/spack/spack/cmd/modules/__init__.py:286 ==> [2019-07-31-16:09:02.101293] Warning:    --> global name 'prefix' is not defined <--



### Information on your system

 1. any relevant configuration detail (custom `packages.yaml` or `modules.yaml`, etc.)
The modules.yaml file is modified:

```
modules:
    tcl:
        naming_scheme: '{name}/{version}/{compiler.name}-{compiler.version}'
        all:
            suffixes:
                ^mpi: "mpi"
                ^cuda: "cuda"
            conflict:
                - '{name}'

        blacklist_implicits: true
        verbose: True
        hash_length: 0
```



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/magma/package.py b/var/spack/repos/builtin/packages/magma/package.py
--- a/var/spack/repos/builtin/packages/magma/package.py
+++ b/var/spack/repos/builtin/packages/magma/package.py
@@ -46,8 +46,8 @@ def cmake_args(self):
         options = []
 
         options.extend([
-            '-DCMAKE_INSTALL_PREFIX=%s' % prefix,
-            '-DCMAKE_INSTALL_NAME_DIR:PATH=%s/lib' % prefix,
+            '-DCMAKE_INSTALL_PREFIX=%s' % self.prefix,
+            '-DCMAKE_INSTALL_NAME_DIR:PATH=%s/lib' % self.prefix,
             '-DBLAS_LIBRARIES=%s' % spec['blas'].libs.joined(';'),
             # As of MAGMA v2.3.0, CMakeLists.txt does not use the variable
             # BLAS_LIBRARIES, but only LAPACK_LIBRARIES, so we need to


Test patch:
Repository: spack/spack

Issue:
py-pyqt5 missing dependency
py-pyqt5 throws error during config phase as shown below. After adding py-enum34 as dependency, package installs.
```
==> Executing phase: 'configure'
==> [2019-07-31-01:05:18.779318] '/disk/software/lib/hpcpm/spack/opt/spack/linux-centos7-x86_64/gcc-9.1.0/python-2.7.16-7zsnkcaqnii7p5exfgiobrjnyo
fv3wrf/bin/python2.7' 'configure.py' '--pyuic5-interpreter' '/disk/software/lib/hpcpm/spack/opt/spack/linux-centos7-x86_64/gcc-9.1.0/python-2.7.16
-7zsnkcaqnii7p5exfgiobrjnyofv3wrf/bin/python2.7' '--verbose' '--confirm-license' '--qmake' '/disk/software/lib/hpcpm/spack/opt/spack/linux-centos7
-x86_64/gcc-9.1.0/qt-5.11.3-zc3mvpbz5oyqoobxgziuaxy3jzpobbbj/bin/qmake' '--sip' '/disk/software/lib/hpcpm/spack/opt/spack/linux-centos7-x86_64/gcc
-9.1.0/py-sip-4.19.18-zj3mdnzwkow6gurjjj2uekqots3jf5h2/bin/sip' '--sip-incdir' '/disk/software/lib/hpcpm/spack/opt/spack/linux-centos7-x86_64/gcc-
9.1.0/py-sip-4.19.18-zj3mdnzwkow6gurjjj2uekqots3jf5h2/include/python2.7' '--bindir' '/disk/software/lib/hpcpm/spack/opt/spack/linux-centos7-x86_64
/gcc-9.1.0/py-pyqt5-5.13.0-4am7wk5li33izrnaqxtvessl7hj3d375/bin' '--destdir' '/disk/software/lib/hpcpm/spack/opt/spack/linux-centos7-x86_64/gcc-9.
1.0/py-pyqt5-5.13.0-4am7wk5li33izrnaqxtvessl7hj3d375/lib/python2.7/site-packages'
Error: Unable to import enum. Please install the enum34 package from PyPI.
Querying qmake about your Qt installation...
```


Discussion:
@adamjstewart

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/py-pyqt5/package.py b/var/spack/repos/builtin/packages/py-pyqt5/package.py
--- a/var/spack/repos/builtin/packages/py-pyqt5/package.py
+++ b/var/spack/repos/builtin/packages/py-pyqt5/package.py
@@ -18,10 +18,12 @@ class PyPyqt5(SIPPackage):
 
     version('5.13.0', sha256='0cdbffe5135926527b61cc3692dd301cd0328dd87eeaf1313e610787c46faff9')
 
+    depends_on('py-sip@4.19.14:')
     # Without opengl support, I got the following error:
     # sip: QOpenGLFramebufferObject is undefined
     depends_on('qt@5:+opengl')
     depends_on('python@2.6:', type=('build', 'run'))
+    depends_on('py-enum34', type=('build', 'run'), when='^python@:3.3')
 
     # https://www.riverbankcomputing.com/static/Docs/PyQt5/installation.html
     def configure_args(self):


Test patch:
Repository: spack/spack

Issue:
Updated prefix in cmake_args for Plasma
Plasma installs correctly (in this instance as part of the xSDK but I've also installed individually) but I'm experiencing the following error when attempting to generate module files.

```bash
$ spack module lmod refresh
...
﻿==> Regenerating lmod module files
==> Warning: Could not write module file [/ecp/sw/dev/ecp-p9-4v100/modulefiles/xsdk/lmod/linux-centos7-ppc64le/netlib-lapack/3.8.0-er4hgnv/gcc/8.3.0/plasma/18.11.1.lua]
==> Warning:    --> global name 'prefix' is not defined <--
```

The fix appears to be using `self.prefix` instead of just `prefix` in the `cmake_args(self)` method. But if this is the wrong approach please let me know. Other posts relating to the "is not defined" error message did not help correct it.

@luszczek hope you don't mind I tag you on this PR since your marked as the maintainer.


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/plasma/package.py b/var/spack/repos/builtin/packages/plasma/package.py
--- a/var/spack/repos/builtin/packages/plasma/package.py
+++ b/var/spack/repos/builtin/packages/plasma/package.py
@@ -21,6 +21,7 @@ class Plasma(CMakePackage):
     maintainers = ['luszczek']
 
     version("develop", hg=hg)
+    version("19.8.1", sha256="3a5db6eabf91aec782b7f27b17a7f6b8ce2c9d8e648c0e9c0ff5d87277ba4d17")
     version("19.8.0", sha256="19a950ade8a7c8d082f372789c9f874274a63217ecff26e33f366402f060f071")
     version("18.11.1", sha256="0581cc8b1188932fd9c29bd258ffe2dc8fb26b1530c5dc3d91f8de369e44edbc")
     version("18.11.0", sha256="36501488be5b4b2b973524824e1afd27779d37addfeeb34c1871ba753b6c06bf")
@@ -71,8 +72,6 @@ def cmake_args(self):
         options = list()
 
         options.extend([
-            "-DCMAKE_INSTALL_PREFIX=%s" % prefix,
-            "-DCMAKE_INSTALL_NAME_DIR:PATH=%s/lib" % prefix,
             "-DBLAS_LIBRARIES=%s" % self.spec["blas"].libs.joined(";"),
             "-DLAPACK_LIBRARIES=%s" % self.spec["lapack"].libs.joined(";")
         ])


Test patch:
Repository: spack/spack

Issue:
Clang always references system gcc, even if being built with spack gcc
### Steps to reproduce the issue

Even when building LLVM with a spack-installed GCC compiler, Clang includes the system GCC installation in its search paths:

```console
$ spack install llvm@7.0.1%gcc@8.2.0
$ $(spack location -i llvm)/bin/clang -print-search-dirs
programs: =/projects/spack/opt/spack/linux-rhel7-x86_64/gcc-8.2.0/llvm-7.0.1-avafczo6dbasez3obndejep4rwbmwnrl/bin:/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../x86_64-redhat-linux/bin
libraries: =/projects/spack/opt/spack/linux-rhel7-x86_64/gcc-8.2.0/llvm-7.0.1-avafczo6dbasez3obndejep4rwbmwnrl/lib/clang/7.0.1:/usr/lib/gcc/x86_64-redhat-linux/4.8.5:/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64:/lib/../lib64:/usr/lib/../lib64:/usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../..:/projects/spack/opt/spack/linux-rhel7-x86_64/gcc-8.2.0/llvm-7.0.1-avafczo6dbasez3obndejep4rwbmwnrl/bin/../lib:/lib:/usr/lib
```

This is the source of a problem that took a long time to debug, wherein a code that's compiled using both Clang (built using GCC 8.2) for C++ and Gfortran (the same GCC 8.2) can link against both the system-provided `libgfortran` and the GCC 8.2 version, even though all the spack-built dependencies correctly use the GCC 8.2 version!:
```console
$ ldd libSenlib.so | grep gfort
	libgfortran.so.3 => /lib64/libgfortran.so.3 (0x00007f9230507000)
	libgfortran.so.5 => /projects/spack/opt/spack/linux-rhel7-x86_64/gcc-4.8.5/gcc-8.2.0-3gf5hj6qpbqqh44sdsnueyyvbnjtbgnh/lib64/libgfortran.so.5 (0x00007f922f577000)
```

The source of this error is that, even though nothing in my CMake configuration references the system GCC, the CMake link command still links against the system path:
```
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.5
```
and thus overrides the GCC 8.2 library.

### Platform and user environment

Please report your OS here:
```commandline
$ uname -a 
Linux node2 3.10.0-327.10.1.el7.x86_64 #1 SMP Sat Jan 23 04:54:55 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -d
Description:	Red Hat Enterprise Linux Workstation release 7.2 (Maipo)
``` 


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/llvm/package.py b/var/spack/repos/builtin/packages/llvm/package.py
--- a/var/spack/repos/builtin/packages/llvm/package.py
+++ b/var/spack/repos/builtin/packages/llvm/package.py
@@ -697,6 +697,10 @@ def cmake_args(self):
         if '+omp_tsan' in spec:
             cmake_args.append('-DLIBOMP_TSAN_SUPPORT=ON')
 
+        if self.compiler.name == 'gcc':
+            gcc_prefix = ancestor(self.compiler.cc, 2)
+            cmake_args.append('-DGCC_INSTALL_PREFIX=' + gcc_prefix)
+
         if spec.satisfies('@4.0.0:') and spec.satisfies('platform=linux'):
             cmake_args.append('-DCMAKE_BUILD_WITH_INSTALL_RPATH=1')
         return cmake_args


Test patch:
Repository: spack/spack

Issue:
Spack Environments cannot handle space in PATH
Spack Environments commands fail in **horrible** ways if your `PATH` contains spaces.

### Steps to reproduce the issue

```console
$ export PATH="/my/fake/path:/my/fake/path/with spaces:$PATH"
$ echo PATH
/my/fake/path:/my/fake/path/with spaces:/Users/Adam/bin:/Users/Adam/miniconda3/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/local/MacGPG2/bin:/opt/X11/bin:/usr/X11/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/usr/local/git/bin:/Users/Adam/spack/bin
$ spack env activate ...
```

### Error Message

```console
-bash: export: `spaces:/Users/Adam/bin:/Users/Adam/miniconda3/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/local/MacGPG2/bin:/opt/X11/bin:/usr/X11/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/usr/local/git/bin:/Users/Adam/spack/bin': not a valid identifier
$ echo $PATH
/Users/Adam/Documents/UIUC/Research/Crops/crop_classification/.spack-env/view/bin:/my/fake/path:/my/fake/path/with
$ which spack
-bash: which: command not found
$ spack env deactivate
-bash: spack: command not found
$ despacktivate
-bash: spack: command not found
```
This is especially troublesome on macOS, where a lot of system libraries are installed in directories containing spaces, like `/Library/Application Support/`. In this case, users do not have an option to avoid spaces in their `PATH`.

@zchen105


Discussion:

Resolving patch:
diff --git a/lib/spack/spack/util/environment.py b/lib/spack/spack/util/environment.py
--- a/lib/spack/spack/util/environment.py
+++ b/lib/spack/spack/util/environment.py
@@ -492,8 +492,8 @@ def shell_modifications(self, shell='sh'):
                 if new is None:
                     cmds += _shell_unset_strings[shell].format(name)
                 else:
-                    cmds += _shell_set_strings[shell].format(name,
-                                                             new_env[name])
+                    cmds += _shell_set_strings[shell].format(
+                        name, cmd_quote(new_env[name]))
         return cmds
 
     @staticmethod


Test patch:
Repository: spack/spack

Issue:
Installation issue: py-adios
### Steps to reproduce the issue
```console
$ spack install -j 64 py-adios ^python@3.0:
```

The result is lots of errors like:
```adios_mpi.cpp:47080:21: error: 'PyThreadState' {aka 'struct _ts'} has no member named 'exc_type'; did you mean 'curexc_type'?```

And similar.

### Platform and user environment
```commandline
$ uname -a
Linux quokka1.ccs.ornl.gov 4.14.0-115.el7a.aarch64 #1 SMP Tue Sep 25 12:32:51 EDT 2018 aarch64 aarch64 aarch64 GNU/Linux
``` 

### Additional information
py-adios includes a file (adios_mpi.cpp) which was generated using Cython 0.28.2.  This version of Cython generates code that won't compile against the Python 3.7 C API.  (This was fixed in the 0.29 release.)  The Adios developers have been notified (https://github.com/ornladios/ADIOS/issues/202).

I think the workaround is to add a ```depends_on()``` line for python <=3.6.x.  If/when the issue is fixed in Adios, we can add a ```when``` clause to the dependency.  I'll issue a pull request shortly.



Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/py-adios/package.py b/var/spack/repos/builtin/packages/py-adios/package.py
--- a/var/spack/repos/builtin/packages/py-adios/package.py
+++ b/var/spack/repos/builtin/packages/py-adios/package.py
@@ -35,6 +35,14 @@ class PyAdios(PythonPackage):
                    when='@{0} +mpi'.format(v),
                    type=['build', 'link', 'run'])
 
+    # NOTE: this dependency is a work-around for a bug in Adios itself.
+    # Specifically, Adios uses code that was generated by Cython 0.28.2.
+    # This code won't compile against the Python 3.7 C API.
+    # See https://github.com/ornladios/ADIOS/issues/202 and
+    # the first entry under "Bug Fixes" at
+    # https://github.com/cython/cython/blob/0.29.x/CHANGES.rst
+    depends_on('python@:3.6')
+
     depends_on('py-numpy', type=['build', 'run'])
     depends_on('mpi', when='+mpi')
     depends_on('py-mpi4py', type=['run'], when='+mpi')


Test patch:
Repository: spack/spack

Issue:
`buildcache list` does not show all binaries from target family
On RHEL7, I have Spack installed packages built with GCC 4.8.5 and also 7.3.0. The ones built with GCC 4.8.5 are tagged `haswell`, the ones built with 7.3.0 are tagged `broadwell`. I have created binaries of ALL these packages and put them in a mirror. `spack buildcache list` only shows me the binaries tagged `broadwell` even though I'm running it on the exact same machine where the packages were originally built.


Discussion:
Note: This is due to lines 613 and 630 in `lib/spack/spack/binary_distribution.py`

It will take slightly more work to come up with a solution.

Resolving patch:
diff --git a/lib/spack/spack/binary_distribution.py b/lib/spack/spack/binary_distribution.py
--- a/lib/spack/spack/binary_distribution.py
+++ b/lib/spack/spack/binary_distribution.py
@@ -610,7 +610,9 @@ def get_specs(force=False):
         tty.warn("No Spack mirrors are currently configured")
         return {}
 
-    path = str(spack.architecture.sys_type())
+    arch = spack.architecture.sys_type()
+    arch_spec = 'platform=%s os=%s target=:%s' % tuple(arch.split('-'))
+
     urls = set()
     for mirror_name, mirror_url in mirrors.items():
         if mirror_url.startswith('file'):
@@ -627,7 +629,7 @@ def get_specs(force=False):
             tty.msg("Finding buildcaches on %s" % mirror_url)
             p, links = spider(mirror_url + "/" + _build_cache_relative_path)
             for link in links:
-                if re.search("spec.yaml", link) and re.search(path, link):
+                if re.search("spec.yaml", link):
                     urls.add(link)
 
     _cached_specs = []
@@ -646,7 +648,8 @@ def get_specs(force=False):
                 # we need to mark this spec concrete on read-in.
                 spec = Spec.from_yaml(f)
                 spec._mark_concrete()
-                _cached_specs.append(spec)
+                if spec.satisfies(arch_spec):
+                    _cached_specs.append(spec)
 
     return _cached_specs
 


Test patch:
Repository: spack/spack

Issue:
Warning: No Spack mirrors are currently configured
Can we get rid of this warning message (at least until Spack mirrors are commonplace)?
```console
==> Installing foo
==> Searching for binary cache of foo
==> Warning: No Spack mirrors are currently configured
==> No binary for foo found: installing from source
```
### Steps to reproduce the issue

```console
$ spack install foo
```


Discussion:
I'll skip the triage step and say I think this could be resolved by making the mirrors warning a debug-level message.

Resolving patch:
diff --git a/lib/spack/spack/binary_distribution.py b/lib/spack/spack/binary_distribution.py
--- a/lib/spack/spack/binary_distribution.py
+++ b/lib/spack/spack/binary_distribution.py
@@ -606,7 +606,7 @@ def get_specs(force=False):
 
     mirrors = spack.config.get('mirrors')
     if len(mirrors) == 0:
-        tty.warn("No Spack mirrors are currently configured")
+        tty.debug("No Spack mirrors are currently configured")
         return {}
 
     urls = set()


Test patch:
Repository: spack/spack

Issue:
update py-line-profiler to work with current python
* unfortunately there is no current release so
  we take a current commit


Discussion:

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/py-line-profiler/package.py b/var/spack/repos/builtin/packages/py-line-profiler/package.py
--- a/var/spack/repos/builtin/packages/py-line-profiler/package.py
+++ b/var/spack/repos/builtin/packages/py-line-profiler/package.py
@@ -3,6 +3,8 @@
 #
 # SPDX-License-Identifier: (Apache-2.0 OR MIT)
 
+import os
+
 from spack import *
 
 
@@ -12,9 +14,20 @@ class PyLineProfiler(PythonPackage):
     homepage = "https://github.com/rkern/line_profiler"
     url      = "https://pypi.io/packages/source/l/line_profiler/line_profiler-2.0.tar.gz"
 
+    version('2.1.2', sha256='efa66e9e3045aa7cb1dd4bf0106e07dec9f80bc781a993fbaf8162a36c20af5c')
     version('2.0', 'fc93c6bcfac3b7cb1912cb28836d7ee6')
 
-    depends_on('python@2.5:')
+    depends_on('python@2.5:', type=('build', 'run'))
     depends_on('py-setuptools',     type='build')
     depends_on('py-cython',         type='build')
     depends_on('py-ipython@0.13:',  type=('build', 'run'))
+
+    # See https://github.com/rkern/line_profiler/issues/166
+    @run_before('build')
+    @when('^python@3.7:')
+    def fix_cython(self):
+        cython = self.spec['py-cython'].command
+        for root, _, files in os.walk('.'):
+            for fn in files:
+                if fn.endswith('.pyx'):
+                    cython(os.path.join(root, fn))


Test patch: