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

Issue:
Small issue in the text of kernel in the heteroskedastic example
*Are there any mistakes in the docs?*
Hi,

In
https://gpflow.readthedocs.io/en/develop/notebooks/advanced/heteroskedastic.html
the explanation of the kernel has an issue when rendering. In my Chrome, it looks like
"withbothkernelsbeingmodeledasseparateandindependent:math:‘SquaredExponential‘kernels."

It does look ok here:
https://github.com/GPflow/docs/blob/develop/doc/source/notebooks/advanced/heteroskedastic.ipynb

Kind regards, 

Ivan



Discussion:

Resolving patch:
diff --git a/doc/source/notebooks/advanced/heteroskedastic.pct.py b/doc/source/notebooks/advanced/heteroskedastic.pct.py
--- a/doc/source/notebooks/advanced/heteroskedastic.pct.py
+++ b/doc/source/notebooks/advanced/heteroskedastic.pct.py
@@ -122,6 +122,7 @@ def plot_distribution(X, Y, loc, scale):
 # This implements the following part of the generative model:
 # $$ f_1(x) \sim \mathcal{GP}(0, k_1(\cdot, \cdot)) $$
 # $$ f_2(x) \sim \mathcal{GP}(0, k_2(\cdot, \cdot)) $$
+#
 # with both kernels being modeled as separate and independent $\text{SquaredExponential}$ kernels.
 
 # %%


Test patch:
Repository: GPflow/GPflow

Issue:
Missing Reference to Manipulating Kernels Page
# Documentation/tutorial notebooks

In the [Kernel Design page](https://gpflow.github.io/GPflow/2.7.0/notebooks/tailor/kernel_design.html), there is a missing reference to the "Manipulating Kernels" notebook at the end. This notebook seems accessible from the old documentations, up to [2.6.4](https://gpflow.github.io/GPflow/2.6.4/notebooks/advanced/kernels.html).

It seems for some reason, this page was removed. Maybe it was considered unnecessary, as some information is given in the getting started page but I disagree. I believe it gives a more comprehensive review of the available kernel implementations, so it would be nice to have it back.

As a side note, for some reason 2.6.4 documentation insist on having dark theme for me, but I like the light theme better. Is there an option to change this? I am forced to clean the cookies to get a light background.


Discussion:
Hi, the kernel notebook still exists, though it has been moved to https://gpflow.github.io/GPflow/2.7.0/notebooks/getting_started/kernels.html and updated somewhat. Thank you for noticing that this broke the link in the kernel design notebook though!

Resolving patch:
diff --git a/doc/sphinx/notebooks/tailor/kernel_design.pct.py b/doc/sphinx/notebooks/tailor/kernel_design.pct.py
--- a/doc/sphinx/notebooks/tailor/kernel_design.pct.py
+++ b/doc/sphinx/notebooks/tailor/kernel_design.pct.py
@@ -136,4 +136,4 @@ def plotkernelfunction(k, ax, xmin=0, xmax=3, other=0):
 # %% [markdown]
 # ## See also
 #
-# For more details on how to manipulate existing kernels (or the one you just created!), we refer to the [Manipulating kernels](../advanced/kernels.ipynb) notebook.
+# For more details on how to manipulate existing kernels (or the one you just created!), please refer to the [kernels](../getting_started/kernels.ipynb) notebook.


Test patch:
Repository: networktocode/ntc-templates

Issue:
Need to raise custom exception
https://github.com/networktocode/ntc-templates/blob/923f9afe679f549d14079c4ec962cc913f784550/ntc_templates/parse.py#L38

Currently `parse_output` raises a generic `Exception`; this needs to be changed to a custom exception that can be properly caught by users of the function.


Discussion:

Resolving patch:
diff --git a/ntc_templates/parse.py b/ntc_templates/parse.py
--- a/ntc_templates/parse.py
+++ b/ntc_templates/parse.py
@@ -12,6 +12,10 @@
     HAS_CLITABLE = False
 
 
+class ParsingException(Exception):
+    """Error that is raised when TextFSM hits an `Error` state."""
+
+
 def _get_template_dir():
     template_dir = os.environ.get("NTC_TEMPLATES_DIR")
     if template_dir is None:
@@ -57,9 +61,7 @@ def parse_output(platform=None, command=None, data=None):
         cli_table.ParseCmd(data, attrs)
         structured_data = _clitable_to_dict(cli_table)
     except clitable.CliTableError as err:
-        raise Exception(  # pylint: disable=broad-exception-raised
-            f'Unable to parse command "{command}" on platform {platform} - {str(err)}'
-        ) from err
+        raise ParsingException(f'Unable to parse command "{command}" on platform {platform} - {str(err)}') from err
         # Invalid or Missing template
         # module.fail_json(msg='parsing error', error=str(e))
         # rather than fail, fallback to return raw text


Test patch:
Repository: pypa/virtualenv

Issue:
Link in extra multiarch include dirs on Mandriva Linux.
See https://bugzilla.mozilla.org/show_bug.cgi?id=759320 for details.



Discussion:

Resolving patch:
diff --git a/virtualenv.py b/virtualenv.py
--- a/virtualenv.py
+++ b/virtualenv.py
@@ -19,6 +19,7 @@
 import zlib
 import errno
 import distutils.sysconfig
+import subprocess
 from distutils.util import strtobool
 import struct
 
@@ -1052,6 +1053,9 @@ def create_environment(home_dir, site_packages=False, clear=False,
 
     install_activate(home_dir, bin_dir, prompt)
 
+def is_executable_file(fpath):
+    return os.path.isfile(fpath) and os.access(fpath, os.X_OK)
+
 def path_locations(home_dir):
     """Return the path locations for the environment (where libraries are,
     where scripts go, etc)"""
@@ -1084,7 +1088,17 @@ def path_locations(home_dir):
         bin_dir = join(home_dir, 'bin')
     elif sys.platform != 'win32':
         lib_dir = join(home_dir, 'lib', py_version)
-        inc_dir = join(home_dir, 'include', py_version + abiflags)
+        multiarch_exec = '/usr/bin/multiarch-platform'
+        if is_executable_file(multiarch_exec):
+            # In Mageia (2) and Mandriva distros the include dir must be like:
+            # virtualenv/include/multiarch-x86_64-linux/python2.7
+            # instead of being virtualenv/include/python2.7
+            p = subprocess.Popen(multiarch_exec, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+            stdout, stderr = p.communicate()
+            # stdout.strip is needed to remove newline character
+            inc_dir = join(home_dir, 'include', stdout.strip(), py_version + abiflags)
+        else:
+            inc_dir = join(home_dir, 'include', py_version + abiflags)
         bin_dir = join(home_dir, 'bin')
     return home_dir, lib_dir, inc_dir, bin_dir
 


Test patch:
Repository: pypa/virtualenv

Issue:
ImportError for Python3
Virtualenv fails to create a python 3 environment, but works on 2.7:

``` bash
$  python3 --version
Python 3.4.1
$ virtualenv --version
1.11.6
$ virtualenv --python=/usr/local/bin/python3 python3project
Running virtualenv with interpreter /usr/local/bin/python3
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/virtualenv.py", line 14, in <module>
    import shutil
  File "/usr/local/Cellar/python3/3.4.1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/shutil.py", line 11, in <module>
    import fnmatch
  File "/usr/local/Cellar/python3/3.4.1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/fnmatch.py", line 15, in <module>
    import functools
  File "/usr/local/Cellar/python3/3.4.1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/functools.py", line 21, in <module>
    from collections import namedtuple
  File "/usr/local/Cellar/python3/3.4.1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/collections/__init__.py", line 17, in <module>
    from reprlib import recursive_repr as _recursive_repr
  File "/usr/local/lib/python2.7/site-packages/reprlib.py", line 3, in <module>
    from repr import *
ImportError: No module named 'repr'
```



Discussion:

Resolving patch:
diff --git a/virtualenv.py b/virtualenv.py
--- a/virtualenv.py
+++ b/virtualenv.py
@@ -8,6 +8,27 @@
 import base64
 import sys
 import os
+
+#
+# RATIONALE:
+# This script is both it's own "host" and "guest".  If it's running in "guest
+# mode" (inside the virtualenv interpreter), it's essentially invoked via:
+#     /path/to/python /path/to/this/script.py
+#
+# Which, by the nature of Python, will put `/path/to/this` on the system path
+# as the first argument.  Now this can cause many subtle bugs, because the
+# rest of the script is now looking to import from the "host" Python version
+# first.  This has been especially troublesome when trying to create a Python
+# 3 "guest" env using a Python 2 "host", but even with minor Python
+# differences, there may been some bleeding between environments that doesn't
+# stand out as obviously.
+#
+# This removes the first argument off the system path, to avoid any accidental
+# usage of the "host" library directories.
+#
+if os.environ.get('VIRTUALENV_INTERPRETER_RUNNING'):
+    del sys.path[0]
+
 import codecs
 import optparse
 import re


Test patch:
Repository: pypa/virtualenv

Issue:
Windows `virtualenv -p python2.7` fails even when `python2.7.exe` exists
The problem stems from [this function](https://github.com/pypa/virtualenv/blob/6d8a4ed81f40223a3f9ea1ba5d11be500d9f667a/virtualenv.py#L1542-L1565) which doesn't honor the windows-specific `PATHEXT`.

Here's a nearly-identical implementation of that function which *does* handle `PATHEXT` expansion: https://github.com/pre-commit/pre-commit/blob/e2bae300fe2794e2ece25d4cd72127238704bb1e/pre_commit/parse_shebang.py#L21-L42

`distutils.spawn.find_executable` has a similar special case, but only attempts `.exe`: https://github.com/python/cpython/blob/9648088e6ccd6d0cc04f450f55628fd8eda3784c/Lib/distutils/spawn.py#L181-L182


Discussion:

Resolving patch:
diff --git a/virtualenv.py b/virtualenv.py
--- a/virtualenv.py
+++ b/virtualenv.py
@@ -22,6 +22,7 @@
 import zlib
 import errno
 import glob
+import distutils.spawn
 import distutils.sysconfig
 import struct
 import subprocess
@@ -1551,11 +1552,7 @@ def resolve_interpreter(exe):
         exe = python_versions[exe]
 
     if os.path.abspath(exe) != exe:
-        paths = os.environ.get('PATH', '').split(os.pathsep)
-        for path in paths:
-            if os.path.exists(join(path, exe)):
-                exe = join(path, exe)
-                break
+        exe = distutils.spawn.find_executable(exe) or exe
     if not os.path.exists(exe):
         logger.fatal('The path %s (from --python=%s) does not exist' % (exe, orig_exe))
         raise SystemExit(3)


Test patch:
Repository: pypa/virtualenv

Issue:
pip 10 will no longer expose pip.main
In pip 10, the `pip.main` function is no longer available, as all internal APIs have been moved to an `_internal` namespace. Virtualenv uses `pip.main` at https://github.com/pypa/virtualenv/blob/master/virtualenv.py#L855 so this needs changing.


Discussion:

Resolving patch:
diff --git a/virtualenv.py b/virtualenv.py
--- a/virtualenv.py
+++ b/virtualenv.py
@@ -858,9 +858,13 @@ def space_path2url(p):
         import tempfile
         import os
 
-        import pip
+        try:
+            from pip._internal import main as _main
+            cert_data = pkgutil.get_data("pip._vendor.certifi", "cacert.pem")
+        except ImportError:
+            from pip import main as _main
+            cert_data = pkgutil.get_data("pip._vendor.requests", "cacert.pem")
 
-        cert_data = pkgutil.get_data("pip._vendor.requests", "cacert.pem")
         if cert_data is not None:
             cert_file = tempfile.NamedTemporaryFile(delete=False)
             cert_file.write(cert_data)
@@ -874,7 +878,7 @@ def space_path2url(p):
                 args += ["--cert", cert_file.name]
             args += sys.argv[1:]
 
-            sys.exit(pip.main(args))
+            sys.exit(_main(args))
         finally:
             if cert_file is not None:
                 os.remove(cert_file.name)


Test patch:
Repository: pypa/virtualenv

Issue:
broken Python 3.3 support due to wheel
With #1176, Python 3.3 support is broken because wheel 0.31 dropped support.

This means that virtualenv 16.0.0 will install fine on a Python 3.3 config, but then fail to create any virtualenvs.

virtualenv should also declare that it doesn't support 3.3


Discussion:
Yes, this is causing all my Travis tox projects to break.

A post release should be made on 16.0 to update the `requires_python` to exclude 3.3.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -108,6 +108,7 @@ def get_version():
         'Programming Language :: Python :: 3.4',
         'Programming Language :: Python :: 3.5',
         'Programming Language :: Python :: 3.6',
+        'Programming Language :: Python :: 3.7',
     ],
     keywords='setuptools deployment installation distutils',
     author='Ian Bicking',
@@ -119,5 +120,5 @@ def get_version():
     py_modules=['virtualenv'],
     packages=['virtualenv_support'],
     package_data={'virtualenv_support': ['*.whl']},
-    python_requires='>=2.7,!=3.0.*,!=3.1.*,!=3.2.*',
+    python_requires='>=2.7,!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*',
     **setup_params)


Test patch:
Repository: pypa/virtualenv

Issue:
Integration with virtualenvwrapper
Congratulations on the rewrite.

I notice that `virtualenvwrapper` doesn't integrate with the new beta:

```
$ mkvirtualenv foo
ERROR: Environment '/Users/brettmz/.virtualenvs/foo' does not contain an activate script.
```

Sure enough - I believe it is looking for a script `activate` - but the script file now depends on the shell - `activate.sh` etc. 

It would be good if this could work somehow - would it be reasonable to create / link a default `activate` script for this case?  Or should virtualenvwrapper be updated?


Discussion:
This seems an oversight on our side, indeed should be just ``activate`` not ``activate.sh``.

Resolving patch:
diff --git a/src/virtualenv/activation/bash/__init__.py b/src/virtualenv/activation/bash/__init__.py
--- a/src/virtualenv/activation/bash/__init__.py
+++ b/src/virtualenv/activation/bash/__init__.py
@@ -12,3 +12,6 @@ def supports(cls, interpreter):
 
     def templates(self):
         yield Path("activate.sh")
+
+    def as_name(self, template):
+        return template.stem
diff --git a/src/virtualenv/activation/via_template.py b/src/virtualenv/activation/via_template.py
--- a/src/virtualenv/activation/via_template.py
+++ b/src/virtualenv/activation/via_template.py
@@ -39,7 +39,11 @@ def replacements(self, creator, dest_folder):
     def _generate(self, replacements, templates, to_folder, creator):
         for template in templates:
             text = self.instantiate_template(replacements, template, creator)
-            (to_folder / template).write_text(text, encoding="utf-8")
+            dest = to_folder / self.as_name(template)
+            dest.write_text(text, encoding="utf-8")
+
+    def as_name(self, template):
+        return template.name
 
     def instantiate_template(self, replacements, template, creator):
         # read text and do replacements


Test patch:
diff --git a/tests/unit/activation/test_bash.py b/tests/unit/activation/test_bash.py
--- a/tests/unit/activation/test_bash.py
+++ b/tests/unit/activation/test_bash.py
@@ -7,7 +7,7 @@ def test_bash(raise_on_non_source_class, activation_tester):
     class Bash(raise_on_non_source_class):
         def __init__(self, session):
             super(Bash, self).__init__(
-                BashActivator, session, "bash", "activate.sh", "sh", "You must source this script: $ source "
+                BashActivator, session, "bash", "activate", "sh", "You must source this script: $ source "
             )
 
     activation_tester(Bash)
Repository: pypa/virtualenv

Issue:
discovery stops if we find a poisened interpreter along the way
Per comments in https://github.com/pypa/virtualenv/issues/1777#issuecomment-616391694


Discussion:

Resolving patch:
diff --git a/src/virtualenv/discovery/py_info.py b/src/virtualenv/discovery/py_info.py
--- a/src/virtualenv/discovery/py_info.py
+++ b/src/virtualenv/discovery/py_info.py
@@ -313,7 +313,13 @@ def from_exe(cls, exe, app_data=None, raise_on_error=True, ignore_cache=False, r
         proposed = from_exe(cls, app_data, exe, raise_on_error=raise_on_error, ignore_cache=ignore_cache)
         # noinspection PyProtectedMember
         if isinstance(proposed, PythonInfo) and resolve_to_host:
-            proposed = proposed._resolve_to_system(app_data, proposed)
+            try:
+                proposed = proposed._resolve_to_system(app_data, proposed)
+            except Exception as exception:
+                if raise_on_error:
+                    raise exception
+                logging.info("ignore %s due cannot resolve system due to %r", proposed.original_executable, exception)
+                proposed = None
         return proposed
 
     @classmethod


Test patch:
diff --git a/tests/unit/discovery/py_info/test_py_info.py b/tests/unit/discovery/py_info/test_py_info.py
--- a/tests/unit/discovery/py_info/test_py_info.py
+++ b/tests/unit/discovery/py_info/test_py_info.py
@@ -297,3 +297,14 @@ def test_py_info_setuptools():
 
     assert Distribution
     PythonInfo()
+
+
+def test_py_info_to_system_raises(session_app_data, mocker, caplog):
+    caplog.set_level(logging.DEBUG)
+    mocker.patch.object(PythonInfo, "_find_possible_folders", return_value=[])
+    result = PythonInfo.from_exe(sys.executable, app_data=session_app_data, raise_on_error=False)
+    assert result is None
+    log = caplog.records[-1]
+    assert log.levelno == logging.INFO
+    expected = "ignore {} due cannot resolve system due to RuntimeError('failed to detect ".format(sys.executable)
+    assert expected in log.message
Repository: pypa/virtualenv

Issue:
.gitignore added to places it should not
Refs #1806

Virtualenv now drops a .gitignore file. While I understand where you are coming from, it is a mistake to assume virtualenv owns the target directory. For example, I and many people I work with typically do this:

```
git clone git@github.com:stefanholek/foo
cd foo
virtualenv .
./bin/pip install -e .
./bin/python -m unittest
```

Recent versions of virtualenv add a .gitignore file into my sandbox. To make matters worse it even **overwrites** an existing .gitignore file! This is very clearly wrong.

I suggest to not write the .gitignore file unless virtualenv has created the target directory, or at least don't write it if the target directory already contains a .git directory and/or a .gitignore file.

Thanks!


Discussion:
> don't write it if the target directory already contains a .git directory and/or a .gitignore file.

I think this makes sense as an improvement.

Resolving patch:
diff --git a/src/virtualenv/create/creator.py b/src/virtualenv/create/creator.py
--- a/src/virtualenv/create/creator.py
+++ b/src/virtualenv/create/creator.py
@@ -168,14 +168,16 @@ def set_pyenv_cfg(self):
     def setup_ignore_vcs(self):
         """Generate ignore instructions for version control systems."""
         # mark this folder to be ignored by VCS, handle https://www.python.org/dev/peps/pep-0610/#registered-vcs
-        (self.dest / ".gitignore").write_text(
-            dedent(
-                """
-                # created by virtualenv automatically
-                *
-                """,
-            ).lstrip(),
-        )
+        git_ignore = self.dest / ".gitignore"
+        if not git_ignore.exists():
+            git_ignore.write_text(
+                dedent(
+                    """
+                    # created by virtualenv automatically
+                    *
+                    """,
+                ).lstrip(),
+            )
         # Mercurial - does not support the .hgignore file inside a subdirectory directly, but only if included via the
         # subinclude directive from root, at which point on might as well ignore the directory itself, see
         # https://www.selenic.com/mercurial/hgignore.5.html for more details


Test patch:
diff --git a/tests/unit/create/test_creator.py b/tests/unit/create/test_creator.py
--- a/tests/unit/create/test_creator.py
+++ b/tests/unit/create/test_creator.py
@@ -237,6 +237,13 @@ def list_to_str(iterable):
     assert git_ignore.splitlines() == ["# created by virtualenv automatically", "*"]
 
 
+def test_create_gitignore_exists(tmp_path):
+    git_ignore = tmp_path / ".gitignore"
+    git_ignore.write_text("magic")
+    cli_run([str(tmp_path), "--without-pip", "--activators", ""])
+    assert git_ignore.read_text() == "magic"
+
+
 @pytest.mark.skipif(not CURRENT.has_venv, reason="requires interpreter with venv")
 def test_venv_fails_not_inline(tmp_path, capsys, mocker):
     if hasattr(os, "geteuid"):
Repository: pypa/virtualenv

Issue:
`virtualenv --version` prints spurious error as of 20.0.24
**Issue**

When running `virtualenv --version`, a logger error is printed to stderr, though the return code is still 0.

**Environment**

Tested with Python 3.7 and 3.8, virtualenvs managed with pipenv
Ubuntu 18.04 on WSL

```
$ rm-rf tmp && mkdir tmp && cd tmp
$ pipenv install "virtualenv==20.0.23"
$ pipenv run virtualenv --version
virtualenv 20.0.23 from tmp/.venv/lib/python3.7/site-packages/virtualenv/__init__.py

$ rm-rf tmp && mkdir tmp && cd tmp
$ pipenv install "virtualenv==20.0.24"
$ pipenv run virtualenv --version
virtualenv 20.0.24 from tmp/.venv/lib/python3.7/site-packages/virtualenv/__init__.py
ERROR:root:SystemExit: 0
$ pipenv run virtualenv --version > /dev/null
ERROR:root:SystemExit: 0
$ echo $?
0
```

Nothing else is printed with `-vvv --with-traceback`


Discussion:

Resolving patch:
diff --git a/src/virtualenv/__main__.py b/src/virtualenv/__main__.py
--- a/src/virtualenv/__main__.py
+++ b/src/virtualenv/__main__.py
@@ -66,7 +66,8 @@ def run_with_catch(args=None):
             if getattr(options, "with_traceback", False):
                 raise
             else:
-                logging.error("%s: %s", type(exception).__name__, exception)
+                if not (isinstance(exception, SystemExit) and exception.code == 0):
+                    logging.error("%s: %s", type(exception).__name__, exception)
                 code = exception.code if isinstance(exception, SystemExit) else 1
                 sys.exit(code)
         finally:


Test patch: