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

Issue:
[Legal] Include the license of all libraries in `_vendor`
### What's the problem this feature will solve?

I'm not a lawyer, but my understanding is that it is not allowed to separate MIT licensed code from its license and copyright.

### Describe the solution you'd like

Include the license of all vendored libraries.

### Alternative Solutions

_No response_

### Additional context

_No response_

### Code of Conduct

- [X] I agree to follow the PSF Code of Conduct


Discussion:

Resolving patch:
diff --git a/pavement.py b/pavement.py
--- a/pavement.py
+++ b/pavement.py
@@ -1,6 +1,7 @@
 import re
 import sys
 import subprocess
+from fnmatch import fnmatch
 
 from paver.easy import task, path as Path
 
@@ -52,12 +53,43 @@ def install(vendor):
         '-t', str(vendor),
     ]
     subprocess.check_call(install_args)
+    move_licenses(vendor)
     remove_all(vendor.glob('*.dist-info'))
     remove_all(vendor.glob('*.egg-info'))
     remove_all(vendor.glob('six.py'))
     (vendor / '__init__.py').write_text('')
 
 
+def move_licenses(vendor):
+    license_patterns = ("*LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*")
+    licenses = (
+        entry
+        for path in vendor.glob("*.dist-info")
+        for entry in path.glob("*")
+        if any(fnmatch(str(entry), p) for p in license_patterns)
+    )
+    for file in licenses:
+        file.move(_find_license_dest(file, vendor))
+
+
+def _find_license_dest(license_file, vendor):
+    basename = license_file.basename()
+    pkg = license_file.dirname().basename().replace(".dist-info", "")
+    parts = pkg.split("-")
+    acc = []
+    for part in parts:
+        # Find actual name from normalized name + version
+        acc.append(part)
+        for option in ("_".join(acc), "-".join(acc), ".".join(acc)):
+            candidate = vendor / option
+            if candidate.isdir():
+                return candidate / basename
+            if Path(f"{candidate}.py").isfile():
+                return Path(f"{candidate}.{basename}")
+
+    raise FileNotFoundError(f"No destination found for {license_file}")
+
+
 def update_pkg_resources():
     vendor = Path('pkg_resources/_vendor')
     install(vendor)


Test patch:
Repository: pypa/setuptools

Issue:
When parsing `pyproject.toml` current implementation will overwrite dist.include_package_data
What I find confusing with the include_package_data explanation is that even if I set it to False manually in setup.py I still see the same weird behavior. Do you expect that ?

_Originally posted by @MatthieuDartiailh in https://github.com/pypa/setuptools/issues/3197#issuecomment-1079036329_


Discussion:

Resolving patch:
diff --git a/setuptools/config/pyprojecttoml.py b/setuptools/config/pyprojecttoml.py
--- a/setuptools/config/pyprojecttoml.py
+++ b/setuptools/config/pyprojecttoml.py
@@ -103,7 +103,10 @@ def read_configuration(
     # the default would be an improvement.
     # `ini2toml` backfills include_package_data=False when nothing is explicitly given,
     # therefore setting a default here is backwards compatible.
-    setuptools_table.setdefault("include-package-data", True)
+    if dist and getattr(dist, "include_package_data") is not None:
+        setuptools_table.setdefault("include-package-data", dist.include_package_data)
+    else:
+        setuptools_table.setdefault("include-package-data", True)
     # Persist changes:
     asdict["tool"] = tool_table
     tool_table["setuptools"] = setuptools_table


Test patch:
diff --git a/setuptools/tests/config/test_pyprojecttoml.py b/setuptools/tests/config/test_pyprojecttoml.py
--- a/setuptools/tests/config/test_pyprojecttoml.py
+++ b/setuptools/tests/config/test_pyprojecttoml.py
@@ -4,6 +4,7 @@
 
 import pytest
 import tomli_w
+from path import Path as _Path
 
 from setuptools.config.pyprojecttoml import (
     read_configuration,
@@ -11,6 +12,9 @@
     validate,
 )
 
+import setuptools  # noqa -- force distutils.core to be patched
+import distutils.core
+
 EXAMPLE = """
 [project]
 name = "myproj"
@@ -292,3 +296,22 @@ def test_include_package_data_by_default(tmp_path, config):
 
     config = read_configuration(pyproject)
     assert config["tool"]["setuptools"]["include-package-data"] is True
+
+
+def test_include_package_data_in_setuppy(tmp_path):
+    """Builds with ``pyproject.toml`` should consider ``include_package_data`` set in
+    ``setup.py``.
+
+    See https://github.com/pypa/setuptools/issues/3197#issuecomment-1079023889
+    """
+    pyproject = tmp_path / "pyproject.toml"
+    pyproject.write_text("[project]\nname = 'myproj'\nversion='42'\n")
+    setuppy = tmp_path / "setup.py"
+    setuppy.write_text("__import__('setuptools').setup(include_package_data=False)")
+
+    with _Path(tmp_path):
+        dist = distutils.core.run_setup("setup.py", {}, stop_after="config")
+
+    assert dist.get_name() == "myproj"
+    assert dist.get_version() == "42"
+    assert dist.include_package_data is False
Repository: pypa/setuptools

Issue:
[BUG] Removal of convert_path break some packages
### setuptools version

setuptools=61.0.0

### Python version

Python 3.9

### OS

all

### Additional environment information

_No response_

### Description

Some packages such as Cartopy have been broken by upgrade to setuptools=61.0.0

https://github.com/SciTools/cartopy/issues/2021

This is because of commit https://github.com/pypa/setuptools/commit/1ee962510ba66578f6069e6a675b3715ad12ac0b which removes the import
```python
from distutils.util import convert_path
```

This should at least be in the changelog as breakage of API

### Expected behavior

Removing import from __init__.py should be documented in the [CHANGES.rst file](https://github.com/pypa/setuptools/blob/main/CHANGES.rst) for version 61.0.0

### How to Reproduce

Try installing Cartopy with lastest setuptools version

### Output

```console
ImportError: cannot import name 'convert_path' from 'setuptools'
```



Discussion:

Resolving patch:
diff --git a/setuptools/__init__.py b/setuptools/__init__.py
--- a/setuptools/__init__.py
+++ b/setuptools/__init__.py
@@ -3,11 +3,13 @@
 import functools
 import os
 import re
+import warnings
 
 import _distutils_hack.override  # noqa: F401
 
 import distutils.core
 from distutils.errors import DistutilsOptionError
+from distutils.util import convert_path as _convert_path
 
 from ._deprecation_warning import SetuptoolsDeprecationWarning
 
@@ -158,6 +160,19 @@ def findall(dir=os.curdir):
     return list(files)
 
 
+@functools.wraps(_convert_path)
+def convert_path(pathname):
+    from inspect import cleandoc
+
+    msg = """
+    The function `convert_path` is considered internal and not part of the public API.
+    Its direct usage by 3rd-party packages is considered deprecated and the function
+    may be removed in the future.
+    """
+    warnings.warn(cleandoc(msg), SetuptoolsDeprecationWarning)
+    return _convert_path(pathname)
+
+
 class sic(str):
     """Treat this string as-is (https://en.wikipedia.org/wiki/Sic)"""
 


Test patch:
diff --git a/setuptools/tests/test_setuptools.py b/setuptools/tests/test_setuptools.py
--- a/setuptools/tests/test_setuptools.py
+++ b/setuptools/tests/test_setuptools.py
@@ -303,3 +303,8 @@ def test_its_own_wheel_does_not_contain_tests(setuptools_wheel):
 
     for member in contents:
         assert '/tests/' not in member
+
+
+def test_convert_path_deprecated():
+    with pytest.warns(setuptools.SetuptoolsDeprecationWarning):
+        setuptools.convert_path('setuptools/tests')
Repository: pypa/setuptools

Issue:
[Docs] Clarify that "Keywords" page is an API reference for `setuptools.setup`
### Summary

https://setuptools.readthedocs.io/en/latest/references/keywords.html has no indicators what those keywords are for.

It also doesn't show up if you search for "setuptools.setup" in the sidebar search, and is generally innaccessible via search engines as well. It also has poor formatting, likely due to mismanaged indentation on the page.

### OS / Environment

_No response_

### Additional Information

It would be good to:

- have an introductory section in the page, describing what it is for -- explicitly mention "setuptools.setup" in this as well.
- provide anchors for each of the keyword arguments.
- fix the indentation for the list of various arguments.


### Code of Conduct

- [X] I agree to follow the PSF Code of Conduct


Discussion:
Hi,
I would like to work on this.
Thanks

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -129,6 +129,12 @@
     },
 }
 
+# Redirect old docs so links and references in the ecosystem don't break
+extensions += ['sphinx_reredirects']
+redirects = {
+    "userguide/keywords": "/deprecated/changed_keywords.html",
+}
+
 # Add support for inline tabs
 extensions += ['sphinx_inline_tabs']
 


Test patch:
Repository: pypa/setuptools

Issue:
[BUG] In editable installs, whether new modules are auto-picked-up depends on whether the distribution contains a package or not
### setuptools version

65.4.1

### Python version

3.10.7

### OS

Arch Linux

### Additional environment information

_No response_

### Description

In a loose (i.e. default) editable install of a distribution containing a single package, adding a toplevel module (out of the package) results in that module being automatically picked up (immediately available for import, without a reinstall).  This corresponds also, I believe, to the old, pre-PEP660 behavior.
On the other hand, if the distribution does not contain a package but a single toplevel module, adding another toplevel module results in that (new) module not being automatically picked up.

### Expected behavior

Consistent behavior in both cases, hopefully matching the legacy behavior (i.e. new toplevel modules are always auto-picked-up).

### How to Reproduce

Write the following pyproject.toml:
```toml
[build-system]
requires = ["setuptools>=64"]
build-backend = "setuptools.build_meta"

[project]
name = "testpkg"
version = "0.0.1"
```

In that directory, create a single package, editably install, create a single (empty) new module, check that the new module can be imported:
```sh
mkdir src; mkdir src/pkg; touch src/pkg/__init__.py; pip install -e .; touch src/mod2.py; python -c 'import pkg, mod2'
```
This succeeds.

Blow away everything (except for pyproject.toml):
```sh
pip uninstall testpkg; rm -rf src
```

Create a single (empty) module, editably install, create another (empty) new module; this new module cannot be imported:
```sh
mkdir src; touch src/mod1.py; pip install -e .; touch src/mod2.py; python -c 'import mod1, mod2'
```
This fails with `ModuleNotFoundError: No module named 'mod2'`

### Output

See above.


Discussion:

Resolving patch:
diff --git a/setuptools/command/editable_wheel.py b/setuptools/command/editable_wheel.py
--- a/setuptools/command/editable_wheel.py
+++ b/setuptools/command/editable_wheel.py
@@ -551,13 +551,18 @@ def _simple_layout(
     False
     >>> _simple_layout(['a', 'a.b'], {"": "src", "a.b": "_ab"}, "/tmp/myproj")
     False
+    >>> # Special cases, no packages yet:
+    >>> _simple_layout([], {"": "src"}, "/tmp/myproj")
+    True
+    >>> _simple_layout([], {"a": "_a", "": "src"}, "/tmp/myproj")
+    False
     """
     layout = {
         pkg: find_package_path(pkg, package_dir, project_dir)
         for pkg in packages
     }
     if not layout:
-        return False
+        return set(package_dir) in ({}, {""})
     parent = os.path.commonpath([_parent_path(k, v) for k, v in layout.items()])
     return all(
         _normalize_path(Path(parent, *key.split('.'))) == _normalize_path(value)


Test patch:
Repository: pypa/setuptools

Issue:
[BUG] setuptools is using deprecated and slated to be removed APIs
### setuptools version

65.4.1

### Python version

3.12

### OS

macOS

### Additional environment information

_No response_

### Description

As described over in the [pip issue tracker](https://github.com/pypa/pip/issues/11501), several long-deprecated Python import related APIs are being removed in Python 3.12.  All of these have been documented as deprecated for years (in most cases, since Python 3.3).  Now is the time to remove them.

However, this is blocked on references to these old APIs in `pkg_resources` which, through twisty mazes, breaks Python 3.12's build because of its vendoring of pip, hence, setuptools, hence pkg_resources.

Here is the [upstream Python ticket](https://github.com/python/cpython/issues/98040) tracking these removals, which contains the APIs that are being removed.  The `pip` issue above has references to the places in `pkg_resources` where these APIs are still being used.

### Expected behavior

Nothing in `pkg_resources`, `setuptools`, or `pip` should reference these long deprecated APIs.

### How to Reproduce

See the description in the [pip issue description](https://github.com/pypa/pip/issues/11501#issue-1402421943).

### Output

See the description in the [pip issue description](https://github.com/pypa/pip/issues/11501#issue-1402421943).


Discussion:

Resolving patch:
diff --git a/pkg_resources/__init__.py b/pkg_resources/__init__.py
--- a/pkg_resources/__init__.py
+++ b/pkg_resources/__init__.py
@@ -2187,10 +2187,10 @@ def resolve_egg_link(path):
     return next(dist_groups, ())
 
 
-register_finder(pkgutil.ImpImporter, find_on_path)
+if hasattr(pkgutil, 'ImpImporter'):
+    register_finder(pkgutil.ImpImporter, find_on_path)
 
-if hasattr(importlib_machinery, 'FileFinder'):
-    register_finder(importlib_machinery.FileFinder, find_on_path)
+register_finder(importlib_machinery.FileFinder, find_on_path)
 
 _declare_state('dict', _namespace_handlers={})
 _declare_state('dict', _namespace_packages={})
@@ -2344,11 +2344,11 @@ def file_ns_handler(importer, path_item, packageName, module):
         return subpath
 
 
-register_namespace_handler(pkgutil.ImpImporter, file_ns_handler)
-register_namespace_handler(zipimport.zipimporter, file_ns_handler)
+if hasattr(pkgutil, 'ImpImporter'):
+    register_namespace_handler(pkgutil.ImpImporter, file_ns_handler)
 
-if hasattr(importlib_machinery, 'FileFinder'):
-    register_namespace_handler(importlib_machinery.FileFinder, file_ns_handler)
+register_namespace_handler(zipimport.zipimporter, file_ns_handler)
+register_namespace_handler(importlib_machinery.FileFinder, file_ns_handler)
 
 
 def null_ns_handler(importer, path_item, packageName, module):


Test patch:
Repository: pypa/setuptools

Issue:
The DeprecationWarning for `declare_namespace` not shows the source package
### Discussed in https://github.com/pypa/setuptools/discussions/3825

<div type='discussions-op-text'>

<sup>Originally posted by **henri-hulski** February 15, 2023</sup>
After upgrading to setuptools 67.3.1 while running any tests with pytest I get the following warning:
```
========================================= warnings summary =========================================
__pypackages__/3.9/lib/pkg_resources/__init__.py:2803
__pypackages__/3.9/lib/pkg_resources/__init__.py:2803
__pypackages__/3.9/lib/pkg_resources/__init__.py:2803
__pypackages__/3.9/lib/pkg_resources/__init__.py:2803
__pypackages__/3.9/lib/pkg_resources/__init__.py:2803
__pypackages__/3.9/lib/pkg_resources/__init__.py:2803
  /home/user/web/project/__pypackages__/3.9/lib/pkg_resources/__init__.py:2803: DeprecationWarning: Implementing implicit namespace packages (as specified in PEP 420) is preferred to `pkg_resources.declare_namespace`. See https://setuptools.pypa.io/en/latest/references/keywords.html#keyword-namespace-packages
    declare_namespace(pkg)
```
I know that `pkg_resources.declare_namespace` is deprecated in 67.3, but the DeprecationWarning makes not clear which package raises the Warning. Seems to be somewhere in my dependencies.</div>


Discussion:

Resolving patch:
diff --git a/pkg_resources/__init__.py b/pkg_resources/__init__.py
--- a/pkg_resources/__init__.py
+++ b/pkg_resources/__init__.py
@@ -2289,6 +2289,7 @@ def declare_namespace(packageName):
     """Declare that package 'packageName' is a namespace package"""
 
     msg = (
+        f"Deprecated call to `pkg_resources.declare_namespace({packageName!r})`.\n"
         "Implementing implicit namespace packages (as specified in PEP 420) "
         "is preferred to `pkg_resources.declare_namespace`. "
         "See https://setuptools.pypa.io/en/latest/references/"


Test patch:
Repository: pypa/setuptools

Issue:
[Docs] Preview pop-up on a link covers the link itself
### Summary

I've come across an issue with that breaks the online documentation completely for me. Whenever I move my mouse pointer over a link to a different part of the documentation, a pop-up appears that covers the link, making it near-impossible to click the link. See this screen recording of the situation that this has manifested first for me:

https://github.com/pypa/setuptools/assets/50332/af946044-7222-4e2d-b090-c771be758598

(On this page: https://setuptools.pypa.io/en/latest/pkg_resources.html)

### OS / Environment

Safari 16.6, macOS 12.6.8.

### Additional Information

IMHO, as it presents itself to me, this feature has downsides that are orders of magnitude bigger that it's upsides. My browser already allows me to preview a page by triple-tapping on the trackpad (macOS) or long-pressing (iOS), so it doesn't add a benefit on these platforms.

---

As an additional note: Even if this feature was implemented in a way where it wouldn't make it impossible to click on some links, it would still be an accessibility issue for me:

I'm on the ADD spectrum and I use my mouse pointer for focussing while reading. It's very natural for me to move my pointer along the text while reading. Such an unavoidable popup will draw my focus away from what I am reading (because it appears when I'm not expecting it and haven't performed an explicit action to make it appear). I'm having this issue also e.g. on GitHub, where some links have pop-ups that appear on mouse hovering.

If you intend on keeping these pop-ups, there is something that you could do to make it a bit less intrusive for people like me (I can't speak for everyone on the ADD spectrum of course): Make the pop-up appear immediately when entering the link's region _and also_ disappear immediately when leaving the region, instead of after a short delay. For example, buttons and links that change appearance while hovering or tool-tips in UIs that appear immediately are much less distracting to me. I think my brain is more likely to associate my action with the appearance of the pop-up and thus able to ignore the stimulus.

But hey, thanks for your work anyways!

### Code of Conduct

- [X] I agree to follow the PSF Code of Conduct


Discussion:

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -114,19 +114,6 @@
     }
 )
 
-# Support tooltips on references
-extensions += ['hoverxref.extension']
-hoverxref_auto_ref = True
-hoverxref_intersphinx = [
-    'python',
-    'pip',
-    'build',
-    'PyPUG',
-    'packaging',
-    'twine',
-    'importlib-resources',
-]
-
 # Add support for linking usernames
 github_url = 'https://github.com'
 github_repo_org = 'pypa'


Test patch:
Repository: pypa/setuptools

Issue:
[BUG] Setuptools 69.0.0 breaks Astropy's setup
### setuptools version

setuptools==69.0.0

### Python version

3.12

### OS

Ubuntu

### Additional environment information

_No response_

### Description

About 15h ago, Astropy's CI started failing to build with
```
ImportError: cannot import name 'newer_group' from 'setuptools.dep_util'
```
This seems to correspond to an [intentional change in setuptools 69](https://setuptools.pypa.io/en/latest/history.html#features).
Nonetheless, from reading the PR that introduced the change (https://github.com/pypa/setuptools/pull/4069), I'm not sure that this was supposed to break immediately. Was this intended ?

### Expected behavior

a deprecation warning instead of a hard error ?

### How to Reproduce

```shell
$ python -c "from setuptools.dep_util import newer_group"
```

### Output

```console
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: cannot import name 'newer_group' from 'setuptools.dep_util' (/private/tmp/venv/lib/python3.12/site-packages/setuptools/dep_util.py)
```



Discussion:
I see, `astropy` was using a function that was imported by `setuptools.dep_util` in order to implement another function.

I think I can prepare a fix quickly...

Resolving patch:
diff --git a/setuptools/dep_util.py b/setuptools/dep_util.py
--- a/setuptools/dep_util.py
+++ b/setuptools/dep_util.py
@@ -4,7 +4,7 @@
 
 
 def __getattr__(name):
-    if name not in ['newer_pairwise_group']:
+    if name not in ['newer_group', 'newer_pairwise_group']:
         raise AttributeError(name)
     warnings.warn(
         "dep_util is Deprecated. Use functions from setuptools.modified instead.",


Test patch:
Repository: pypa/setuptools

Issue:
setuptools changes underscore to dash for package name
After I pip install cx_oracle, I use python -m pip show cx_oracle command and it shows the package name is cx-Oracle
After discussed with cx_Oracle's author, it shows setuptools changed the underscore to dash for the package name.  Is that an issue for setuptools or is there any way to stop this auto-conversion? Thanks.

setup.cfg for cx_Oracle
[metadata]
name = cx_Oracle

PKG-INFO for cx_Oracle
Metadata-Version: 2.1
Name: cx-Oracle

setup.py used in cx_Oracel
# setup the extension
extension = setuptools.Extension(
        name = "cx_Oracle",
        include_dirs = includeDirs,
        extra_compile_args = extraCompileArgs,
        define_macros = [("CXO_BUILD_VERSION", BUILD_VERSION)],
        extra_link_args = extraLinkArgs,
        sources = sources + dpiSources,
        depends = depends,
        libraries = libraries,
        library_dirs = libraryDirs)


Discussion:
It looks like when [Setuptools resolves the name for the metadata](https://github.com/pypa/setuptools/blob/6b44f948ca40ee490c59d216a0e859d17431742a/setuptools/command/egg_info.py#L124), it uses [pkg_resources.safe_name](https://github.com/pypa/setuptools/blob/6b44f948ca40ee490c59d216a0e859d17431742a/pkg_resources/__init__.py#L1304-L1309), referencing the "[unspecified] standard distribution name" that replaces underscores with dashes.

But looking at recent PEPs like PEP 508, it does look like [Names](https://www.python.org/dev/peps/pep-0508/#names) are allowed to contain underscores.

Probably egg_info needs to be updated to allow for underscores (and anything else allowed be the new standard). Who knows what havoc that will wreak.
This is still an issue.
This is still an issue for me as well

Resolving patch:
diff --git a/setuptools/_normalization.py b/setuptools/_normalization.py
--- a/setuptools/_normalization.py
+++ b/setuptools/_normalization.py
@@ -12,7 +12,7 @@
 
 # https://packaging.python.org/en/latest/specifications/core-metadata/#name
 _VALID_NAME = re.compile(r"^([A-Z0-9]|[A-Z0-9][A-Z0-9._-]*[A-Z0-9])$", re.I)
-_UNSAFE_NAME_CHARS = re.compile(r"[^A-Z0-9.]+", re.I)
+_UNSAFE_NAME_CHARS = re.compile(r"[^A-Z0-9._-]+", re.I)
 _NON_ALPHANUMERIC = re.compile(r"[^A-Z0-9]+", re.I)
 _PEP440_FALLBACK = re.compile(r"^v?(?P<safe>(?:[0-9]+!)?[0-9]+(?:\.[0-9]+)*)", re.I)
 
@@ -35,6 +35,8 @@ def safe_name(component: str) -> str:
     'hello-world'
     >>> safe_name("hello?world")
     'hello-world'
+    >>> safe_name("hello_world")
+    'hello_world'
     """
     # See pkg_resources.safe_name
     return _UNSAFE_NAME_CHARS.sub("-", component)


Test patch: