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

Issue:
[REQUEST] FLOPS Profiler support `scaled_dot_product_attention` and `__matmul__`
Currently, the flops profiler does not handle `F.scaled_dot_product_attention` in transformer models. And it also cannot get flops of expreesions like `a@b`. These defects affect the flops results.


Flops profile should handle the cases decribed above.


Discussion:

Resolving patch:
diff --git a/deepspeed/profiling/flops_profiler/profiler.py b/deepspeed/profiling/flops_profiler/profiler.py
--- a/deepspeed/profiling/flops_profiler/profiler.py
+++ b/deepspeed/profiling/flops_profiler/profiler.py
@@ -827,6 +827,15 @@ def _elementwise_flops_compute(input, other):
         return flops, 0
 
 
+def _attn_flops_compute(q, k, v, *args, **kwargs):
+    """
+    Count flops for the scaled_dot_product_attention operation.
+    """
+    macs = _prod(q.shape) * k.shape[-2]
+    macs += _prod(q.shape[:-1]) * k.shape[-2] * v.shape[-1]
+    return 2 * macs, macs
+
+
 def wrapFunc(func, funcFlopCompute):
     oldFunc = func
     name = func.__str__
@@ -899,10 +908,14 @@ def _patch_functionals():
     # embedding
     F.embedding = wrapFunc(F.embedding, _embedding_flops_compute)
 
+    # attn
+    F.scaled_dot_product_attention = wrapFunc(F.scaled_dot_product_attention, _attn_flops_compute)
+
 
 def _patch_tensor_methods():
     torch.matmul = wrapFunc(torch.matmul, _matmul_flops_compute)
     torch.Tensor.matmul = wrapFunc(torch.Tensor.matmul, _matmul_flops_compute)
+    torch.Tensor.__matmul__ = wrapFunc(torch.Tensor.__matmul__, _matmul_flops_compute)
     torch.mm = wrapFunc(torch.mm, _matmul_flops_compute)
     torch.Tensor.mm = wrapFunc(torch.Tensor.mm, _matmul_flops_compute)
     torch.bmm = wrapFunc(torch.bmm, _matmul_flops_compute)


Test patch:
Repository: microsoft/DeepSpeed

Issue:
nv-sd CI test failure
The Nightly CI for https://github.com/microsoft/DeepSpeed/actions/runs/7073374056 failed.



Discussion:

Resolving patch:
diff --git a/deepspeed/model_implementations/diffusers/unet.py b/deepspeed/model_implementations/diffusers/unet.py
--- a/deepspeed/model_implementations/diffusers/unet.py
+++ b/deepspeed/model_implementations/diffusers/unet.py
@@ -68,7 +68,8 @@ def _forward(self,
                  encoder_hidden_states,
                  return_dict=True,
                  cross_attention_kwargs=None,
-                 timestep_cond=None):
+                 timestep_cond=None,
+                 added_cond_kwargs=None):
         if cross_attention_kwargs:
             return self.unet(sample,
                              timestamp,


Test patch:
Repository: microsoft/DeepSpeed

Issue:
nv-sd CI test failure
The Nightly CI for https://github.com/microsoft/DeepSpeed/actions/runs/7434747598 failed.



Discussion:

Resolving patch:
diff --git a/deepspeed/module_inject/containers/vae.py b/deepspeed/module_inject/containers/vae.py
--- a/deepspeed/module_inject/containers/vae.py
+++ b/deepspeed/module_inject/containers/vae.py
@@ -13,11 +13,11 @@ def __init__(self):
         super().__init__()
         try:
             import diffusers
-            if hasattr(diffusers.models.vae, "AutoencoderKL"):
-                self._orig_layer_class = diffusers.models.vae.AutoencoderKL
+            if hasattr(diffusers.models.autoencoders.vae, "AutoencoderKL"):
+                self._orig_layer_class = diffusers.models.autoencoders.vae.AutoencoderKL
             else:
                 # Diffusers >= 0.12.0 changes location of AutoencoderKL
-                self._orig_layer_class = diffusers.models.autoencoder_kl.AutoencoderKL
+                self._orig_layer_class = diffusers.models.autoencoders.autoencoder_kl.AutoencoderKL
         except ImportError:
             self._orig_layer_class = None
 


Test patch:
Repository: microsoft/DeepSpeed

Issue:
[BUG] fp_quantizer is not correctly built when non-jit installation
**Describe the bug**
fp_quantizer is not correctly built when non-jit installation.

**To Reproduce**
Steps to reproduce the behavior:
```
DS_BUILD_FP_QUANTIZER=1 pip install deepspeed
```
install will succeed but
```
from deepspeed.ops.fp_quantizer import FP_Quantize
FP_Quantize()
```
will raise `ImportError: dynamic module does not define module export function (PyInit_fp_quantizer_op)`

**Expected behavior**

Renaming csrc/fp_quantizer/quantize.cu may solve the issue.
This restriction seems to be cause of the bug.
> Note that setuptools cannot handle files with the same name but different extensions
https://pytorch.org/tutorials/advanced/cpp_extension.html



Discussion:
Thanks for pointing this out @twaka - we will take a look

Resolving patch:
diff --git a/op_builder/fp_quantizer.py b/op_builder/fp_quantizer.py
--- a/op_builder/fp_quantizer.py
+++ b/op_builder/fp_quantizer.py
@@ -52,8 +52,8 @@ def filter_ccs(self, ccs):
 
     def sources(self):
         return [
-            "csrc/fp_quantizer/quantize.cu",
-            "csrc/fp_quantizer/quantize.cpp",
+            "csrc/fp_quantizer/fp_quantize.cu",
+            "csrc/fp_quantizer/fp_quantize.cpp",
         ]
 
     def extra_ldflags(self):


Test patch:
Repository: pypa/setuptools

Issue:
Unfriendly error message when unicode is passed to package_dir or packages
Originally reported by: **jaraco (Bitbucket: [jaraco](http://bitbucket.org/jaraco), GitHub: [jaraco](http://github.com/jaraco))**

---

Adding `__future__.unicode_literals` causes setup.py scripts to fail. In the mailman project, here is an example error when running python2 setup.py build:

```
running build
running build_py
Traceback (most recent call last):
  File "setup.py", line 112, in <module>
    test_suite = 'nose2.collector.collector',
  File "C:\Program Files\Python27\lib\distutils\core.py", line 152, in setup
    dist.run_commands()
  File "C:\Program Files\Python27\lib\distutils\dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "C:\Program Files\Python27\lib\distutils\dist.py", line 972, in run_command
    cmd_obj.run()
  File "C:\Program Files\Python27\lib\distutils\command\build.py", line 127, in run
    self.run_command(cmd_name)
  File "C:\Program Files\Python27\lib\distutils\cmd.py", line 326, in run_command
    self.distribution.run_command(command)
  File "C:\Program Files\Python27\lib\distutils\dist.py", line 972, in run_command
    cmd_obj.run()
  File "build\bdist.win-amd64\egg\setuptools\command\build_py.py", line 42, in run
  File "C:\Program Files\Python27\lib\distutils\command\build_py.py", line 372, in build_packages
    self.build_module(module, module_file, package)
  File "build\bdist.win-amd64\egg\setuptools\command\build_py.py", line 60, in build_module
  File "C:\Program Files\Python27\lib\distutils\command\build_py.py", line 333, in build_module
    "'package' must be a string (dot-separated), list, or tuple")
TypeError: 'package' must be a string (dot-separated), list, or tuple
```

A different error occurs when using 'develop':

```
running develop
error: 'egg_base' must be a directory name (got `src`)
```

Setuptools could make this error message nicer.

---
- Bitbucket: https://bitbucket.org/pypa/setuptools/issue/190



Discussion:

Resolving patch:
diff --git a/setuptools/command/build_py.py b/setuptools/command/build_py.py
--- a/setuptools/command/build_py.py
+++ b/setuptools/command/build_py.py
@@ -8,6 +8,7 @@
 import distutils.errors
 import itertools
 
+from setuptools.extern import six
 from setuptools.extern.six.moves import map, filter, filterfalse
 
 try:
@@ -66,6 +67,9 @@ def __getattr__(self, attr):
         return orig.build_py.__getattr__(self, attr)
 
     def build_module(self, module, module_file, package):
+        if six.PY2 and isinstance(package, six.string_types):
+            # avoid errors on Python 2 when unicode is passed (#190)
+            package = package.split('.')
         outfile, copied = orig.build_py.build_module(self, module, module_file,
                                                      package)
         if copied:


Test patch:
Repository: pypa/setuptools

Issue:
WindowsError installing a package with a non-ascii filename
Originally reported in cherrypy/cherrypy#1467, `easy_install` will crash when attempting to build a bdist_egg for a package which contains a file whose filename has non-ascii characters. The issue occurs in `rmtree` even if the stdlib rmtree is used.



Discussion:
It's [a bug in python](http://bugs.python.org/issue24672), which appears to have a long sordid history. The failure is happening because a bytestring is being passed to `shutil.rmtree` or the equivalent, which on Windows returns broken filenames. It's probably straightforward to work around the issue by ensuring that the parameter to shutil.rmtree is unicode.

Interestingly, I've discovered that the issue also only seems to happen if the sdist is a zip file. When the sdist is a tar.gz, the extract step seems to silently discard the unicode filename.


Resolving patch:
diff --git a/setuptools/command/easy_install.py b/setuptools/command/easy_install.py
--- a/setuptools/command/easy_install.py
+++ b/setuptools/command/easy_install.py
@@ -627,7 +627,7 @@ def check_editable(self, spec):
             )
 
     def easy_install(self, spec, deps=False):
-        tmpdir = tempfile.mkdtemp(prefix=six.u("easy_install-"))
+        tmpdir = tempfile.mkdtemp(prefix="easy_install-")
         if not self.editable:
             self.install_site_py()
 


Test patch:
Repository: pypa/setuptools

Issue:
setuptools 25.1.4 adds extra quotes on LIBPATH
#715's quoting has caused my appveyor builds to start failing with 25.1.4, due to some extra quoting.

With setuptools 25.1.3, builds [succeed](https://ci.appveyor.com/project/minrk/pyzmq/build/master+97/job/b5xoge86se10eh3a), and with 25.1.4 they [fail](https://ci.appveyor.com/project/minrk/pyzmq/build/master+98/job/80o5mu31egb6s946).

The key difference:

on 25.1.3, the link command had args like:

```
"/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB"
```

on 25.1.4, they look like:

```
"/LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\LIB""
```

(note the extra quotes).

These are CPython 3.5 x86 builds on appveyor; I don't know what other versions are affected.



Discussion:

Resolving patch:
diff --git a/setuptools/msvc.py b/setuptools/msvc.py
--- a/setuptools/msvc.py
+++ b/setuptools/msvc.py
@@ -233,10 +233,11 @@ def msvc14_library_dir_option(self, dir):
     ------
     "\LIBPATH" argument: str
     """
-    if ' ' in dir and '"' not in dir:
+    opt = unpatched['msvc14_library_dir_option'](self, dir)
+    if ' ' in opt and '"' not in opt:
         # Quote if space and not already quoted
-        dir = '"%s"' % dir
-    return unpatched['msvc14_library_dir_option'](self, dir)
+        opt = '"%s"' % opt
+    return opt
 
 
 def _augment_exception(exc, version, arch=''):


Test patch:
Repository: pypa/setuptools

Issue:
Setuptools doesn't play nice with Numpy
See: https://github.com/numpy/numpy/blob/master/numpy/distutils/extension.py#L42-L52

That functionality was broken by:
https://github.com/pypa/setuptools/blob/master/setuptools/extension.py#L39-L41

In this pr: https://github.com/pypa/setuptools/pull/718

Here's the the pdb session where I debugged this:

```
(Pdb) old_Extension.__module__
'setuptools.extension'
```



Discussion:
Oops, I just sunk some time because of this and (wrongly) traced it to #728. Only after creating a simple travis build to illustrate this did I think about looking at the newest issues.

Currently it seems impossible to install numpy from source on a Unix system, as this build illustrates:

[![Build Status](https://travis-ci.org/tlandschoff-scale/setup-numpy-test.svg?branch=master)](https://travis-ci.org/tlandschoff-scale/setup-numpy-test)

It seems like @bcbrown is correct about the location of this problem.


Resolving patch:
diff --git a/setuptools/extension.py b/setuptools/extension.py
--- a/setuptools/extension.py
+++ b/setuptools/extension.py
@@ -36,9 +36,11 @@ def _have_cython():
 class Extension(_Extension):
     """Extension that uses '.c' files in place of '.pyx' files"""
 
-    def __init__(self, name, sources, py_limited_api=False, **kw):
-        self.py_limited_api = py_limited_api
-        _Extension.__init__(self, name, sources, **kw)
+    def __init__(self, name, sources, *args, **kw):
+        # The *args is needed for compatibility as calls may use positional
+        # arguments. py_limited_api may be set only via keyword.
+        self.py_limited_api = kw.pop("py_limited_api", False)
+        _Extension.__init__(self, name, sources, *args, **kw)
 
     def _convert_pyx_sources_to_lang(self):
         """


Test patch:
Repository: pypa/setuptools

Issue:
py_limited_api calculates extension module filename incorrectly
In https://github.com/pypa/setuptools/blob/2a0db96ee5e78a4d555cbd7288029cbd975c5976/setuptools/command/build_ext.py#L113-L116 a suffix of `get_config_var("SO")` is removed from the filename calculated by the superclass; however, the actual suffix that the superclass uses is `get_config_var("EXT_SUFFIX")`: https://github.com/python/cpython/blob/a9e7db8845551e5639e1fa8030a0482363501fa2/Lib/distutils/command/build_ext.py#L680. As these two values are the same on many platforms, this problem is often hidden, but where they are not the same (eg. CPython 3.3 on Linux), the generated extension filename is wrong and fails to import (it'll be something like `foo.cpython-33m.abi3.so`).

(Thanks to @dstufft for tracking down the exact misbehaviour causing this)



Discussion:

Resolving patch:
diff --git a/setuptools/command/build_ext.py b/setuptools/command/build_ext.py
--- a/setuptools/command/build_ext.py
+++ b/setuptools/command/build_ext.py
@@ -111,7 +111,7 @@ def get_ext_filename(self, fullname):
                 and get_abi3_suffix()
             )
             if use_abi3:
-                so_ext = get_config_var('SO')
+                so_ext = get_config_var('EXT_SUFFIX')
                 filename = filename[:-len(so_ext)]
                 filename = filename + get_abi3_suffix()
             if isinstance(ext, Library):


Test patch:
Repository: pypa/setuptools

Issue:
ImportError: cannot import name monkey
```
user@hostname:~/project$ venv/bin/pip install -U setuptools==27.1.0
Collecting setuptools==27.1.0
  Downloading setuptools-27.1.0-py2.py3-none-any.whl (464kB)
    100% |████████████████████████████████| 471kB 1.6MB/s 
Installing collected packages: setuptools
  Found existing installation: setuptools 27.1.1
    Uninstalling setuptools-27.1.1:
      Successfully uninstalled setuptools-27.1.1
Successfully installed setuptools-27.1.0
user@hostname:~/project$ venv/bin/python -c "import setuptools"
user@hostname:~/project$ venv/bin/pip install -U setuptools==27.1.1
Collecting setuptools==27.1.1
  Using cached setuptools-27.1.1-py2.py3-none-any.whl
Installing collected packages: setuptools
  Found existing installation: setuptools 27.1.0
    Uninstalling setuptools-27.1.0:
      Successfully uninstalled setuptools-27.1.0
Successfully installed setuptools-27.1.1
user@hostname:~/project$ venv/bin/python -c "import setuptools"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/user/project/venv/local/lib/python2.7/site-packages/setuptools/__init__.py", line 13, in <module>
    from setuptools.extension import Extension
  File "/home/user/project/venv/local/lib/python2.7/site-packages/setuptools/extension.py", line 9, in <module>
    from .monkey import get_unpatched
  File "/home/user/project/venv/local/lib/python2.7/site-packages/setuptools/monkey.py", line 10, in <module>
    from . import msvc
  File "/home/user/project/venv/local/lib/python2.7/site-packages/setuptools/msvc.py", line 27, in <module>
    from . import monkey
ImportError: cannot import name monkey
user@hostname:~/project$ 
```



Discussion:
This just started happening with the most recent version on pypi. I would say this is pretty urgent!

In case it isn't obvious, the log demonstrates that 27.1.0 is ok while 27.1.1 throws the error.

This is a circular import `setuptools/__init__.py` => `setuptools/monkey.py` => `setuptools/__init__.py`

Probably introduced here:
https://github.com/pypa/setuptools/commit/b3b6751926037b55c45787192719b7f9372622a8

same here on my windows machine
Running Python 2.7.11 and 2.7.12


Resolving patch:
diff --git a/setuptools/monkey.py b/setuptools/monkey.py
--- a/setuptools/monkey.py
+++ b/setuptools/monkey.py
@@ -7,7 +7,6 @@
 import platform
 
 import setuptools
-from . import msvc
 
 
 __all__ = []
@@ -112,6 +111,8 @@ def patch_for_msvc_specialized_compiler():
     Patch functions in distutils to use standalone Microsoft Visual C++
     compilers.
     """
+    from . import msvc
+
     try:
         # Distutil file for MSVC++ 9.0 and upper (Python 2.7 to 3.4)
         import distutils.msvc9compiler as msvc9compiler


Test patch:
Repository: pypa/setuptools

Issue:
Discrepancy between setuptools and distutils in sdist without MANIFEST.in
Originally reported by: **ikelos (Bitbucket: [ikelos](http://bitbucket.org/ikelos), GitHub: [ikelos](http://github.com/ikelos))**

---

[This upstream bug](http://bugs.python.org/issue2279) (fixed in to 2010) resolved the need to create a MANIFEST.in file as well as list data_files in the setup.py.  This does not appear to have been fixed in setuptools, and as such sdist and similar functions fail to include the appropriate files on machines that have setuptools, but not those that don't, when a fallback import system is used...

Would it be possible to align the two again so that setuptools is again a drop-in replacement for distutils?

---
- Bitbucket: https://bitbucket.org/pypa/setuptools/issue/274

Setuptools' sdist doesn't use data_files while distutils does
Originally reported by: **ionelmc (Bitbucket: [ionelmc](http://bitbucket.org/ionelmc), GitHub: [ionelmc](http://github.com/ionelmc))**

---

Distutils has this: https://github.com/python/cpython/blob/master/Lib/distutils/command/sdist.py#L270-L282

However that code is not copies in the sdist provided by setuptools. 

This can be problematic if you don't inlcude a file in MANIFEST.in but you have it in data_files - python's docs will most certainly mislead you as they say that sdist uses data_files: https://docs.python.org/3/distutils/sourcedist.html?highlight=data_files#specifying-the-files-to-distribute (last bullet)

---
- Bitbucket: https://bitbucket.org/pypa/setuptools/issue/521



Discussion:
_Original comment by_ **jaraco (Bitbucket: [jaraco](http://bitbucket.org/jaraco), GitHub: [jaraco](http://github.com/jaraco))**:

---

Sounds like the right thing to do. A pull request would be most appreciated.

Here's an updated link to the distutils code with the line numbers matching: https://github.com/python/cpython/blob/8ed7551d57a6563fe9d8afaac2b12ff9e86e77ae/Lib/distutils/command/sdist.py#L270-L282


Resolving patch:
diff --git a/setuptools/command/sdist.py b/setuptools/command/sdist.py
--- a/setuptools/command/sdist.py
+++ b/setuptools/command/sdist.py
@@ -141,11 +141,6 @@ def _add_defaults_python(self):
                     self.filelist.extend([os.path.join(src_dir, filename)
                                           for filename in filenames])
 
-    def _add_defaults_data_files(self):
-        """
-        Don't add any data files, but why?
-        """
-
     def check_readme(self):
         for f in self.READMES:
             if os.path.exists(f):


Test patch:
Repository: pypa/setuptools

Issue:
Warning not filtered as supposed to
The warning emitted for missing standard script name in [py36compat.py](https://github.com/pypa/setuptools/blob/master/setuptools/command/py36compat.py#L76) is not suppressed by [`manifest_maker.warn`](https://github.com/pypa/setuptools/blob/master/setuptools/command/egg_info.py#L558) but seems to be supposed to.

I found this while exploring a setup.py as a directory containing a `__main__.py`.  I happened to run

```
python setup.py/__main__.py
```

and I had a warning about the file `__main__.py` missing.

You can suppress the warning by using the `script_name` keyword argument of `setuptools.setup` like so:

```
from setuptools import setup

setup(
    name="mypackage",
    # ... a plethora of other kwargs
    script_name="setup.py"
)
```



Discussion:
Seems reasonable. Can you send a pull request?


Resolving patch:
diff --git a/setuptools/command/egg_info.py b/setuptools/command/egg_info.py
--- a/setuptools/command/egg_info.py
+++ b/setuptools/command/egg_info.py
@@ -554,10 +554,17 @@ def write_manifest(self):
         msg = "writing manifest file '%s'" % self.manifest
         self.execute(write_file, (self.manifest, files), msg)
 
-    def warn(self, msg):  # suppress missing-file warnings from sdist
-        if not msg.startswith("standard file not found:"):
+    def warn(self, msg):
+        if not self._should_suppress_warning(msg):
             sdist.warn(self, msg)
 
+    @staticmethod
+    def _should_suppress_warning(msg):
+        """
+        suppress missing-file warnings from sdist
+        """
+        return re.match(r"standard file .*not found", msg)
+
     def add_defaults(self):
         sdist.add_defaults(self)
         self.filelist.append(self.template)


Test patch:
diff --git a/setuptools/tests/test_egg_info.py b/setuptools/tests/test_egg_info.py
--- a/setuptools/tests/test_egg_info.py
+++ b/setuptools/tests/test_egg_info.py
@@ -4,7 +4,7 @@
 import stat
 import sys
 
-from setuptools.command.egg_info import egg_info
+from setuptools.command.egg_info import egg_info, manifest_maker
 from setuptools.dist import Distribution
 from setuptools.extern.six.moves import map
 
@@ -237,6 +237,15 @@ def test_python_requires_install(self, tmpdir_cwd, env):
         pkginfo = os.path.join(egg_info_dir, 'PKG-INFO')
         assert 'Requires-Python: >=1.2.3' in open(pkginfo).read().split('\n')
 
+    def test_manifest_maker_warning_suppresion(self):
+        fixtures = [
+            "standard file not found: should have one of foo.py, bar.py",
+            "standard file 'setup.py' not found"
+        ]
+
+        for msg in fixtures:
+            assert manifest_maker._should_suppress_warning(msg)
+
     def _run_install_command(self, tmpdir_cwd, env, cmd=None, output=None):
         environ = os.environ.copy().update(
             HOME=env.paths['home'],
Repository: pypa/setuptools

Issue:
Graft with Asterisk broken after 28.4.0
28.4.0 is the last release where `graft */data` as an example, was working. After that release, there is a warning that `warning: no directories found matching '*/data'`


Discussion:
Probably related to #764. @timheap, can you investigate?
I was able to isolate the issue to this commit

commit bb45468d27615c2ce9f9c9757a367c44d6ee80d2
| | Author: Tim Heap
| | Date:   Tue Aug 16 16:40:10 2016 +1000
| |
| |     Much faster implementation of FileList, for big egg_info speedups

Resolving patch:
diff --git a/setuptools/command/egg_info.py b/setuptools/command/egg_info.py
--- a/setuptools/command/egg_info.py
+++ b/setuptools/command/egg_info.py
@@ -429,7 +429,9 @@ def recursive_exclude(self, dir, pattern):
 
     def graft(self, dir):
         """Include all files from 'dir/'."""
-        found = distutils.filelist.findall(dir)
+        found = []
+        for match_dir in glob(dir):
+            found += distutils.filelist.findall(match_dir)
         self.extend(found)
         return bool(found)
 


Test patch:
diff --git a/setuptools/tests/test_manifest.py b/setuptools/tests/test_manifest.py
--- a/setuptools/tests/test_manifest.py
+++ b/setuptools/tests/test_manifest.py
@@ -206,6 +206,15 @@ def test_graft(self):
             l('app/static/app.css'), l('app/static/app.css.map')])
         assert files == self.get_files()
 
+    def test_graft_glob_syntax(self):
+        """Include the whole app/static/ directory."""
+        l = make_local_path
+        self.make_manifest("graft */static")
+        files = default_files | set([
+            l('app/static/app.js'), l('app/static/app.js.map'),
+            l('app/static/app.css'), l('app/static/app.css.map')])
+        assert files == self.get_files()
+
     def test_graft_global_exclude(self):
         """Exclude all *.map files in the project."""
         l = make_local_path