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

Issue:
torch.div() (1.6.0) does not have 'rounding_mode' parameter
According to the torch 1.6.0 here: https://pytorch.org/docs/1.6.0/generated/torch.div.html?highlight=torch%20div#torch.div
there is no 'rounding_mode' parameter. 

But in translator:
https://github.com/OpenNMT/OpenNMT-py/blob/0f411ce11a83b18c0223ac94ccc11a35403763df/onmt/translate/beam_search.py#L282

That's why I receive this error:
```
onmt_translate -model ./../output/test/nmt/f0/run/model_step_100.pt -src ./../output/test/nmt/f0/src-test.txt -output ./../output/test/nmt/f0/test.epoch100.pred.csv -gpu 0 --min_length 2 -verbose 
[2022-09-15 20:32:19,980 INFO] Translating shard 0.
Traceback (most recent call last):
  File "c:\programdata\anaconda3\envs\nuecg\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "c:\programdata\anaconda3\envs\nuecg\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\ProgramData\Anaconda3\envs\nuecg\Scripts\onmt_translate.exe\__main__.py", line 7, in <module>
  File "c:\programdata\anaconda3\envs\nuecg\lib\site-packages\onmt\bin\translate.py", line 54, in main
    translate(opt)
  File "c:\programdata\anaconda3\envs\nuecg\lib\site-packages\onmt\bin\translate.py", line 38, in translate
    align_debug=opt.align_debug
  File "c:\programdata\anaconda3\envs\nuecg\lib\site-packages\onmt\translate\translator.py", line 440, in translate
    phrase_table=phrase_table)
  File "c:\programdata\anaconda3\envs\nuecg\lib\site-packages\onmt\translate\translator.py", line 487, in _translate
    batch, data.src_vocabs, attn_debug
  File "c:\programdata\anaconda3\envs\nuecg\lib\site-packages\onmt\translate\translator.py", line 861, in translate_batch
    batch, src_vocabs, decode_strategy
  File "c:\programdata\anaconda3\envs\nuecg\lib\site-packages\onmt\translate\translator.py", line 947, in _translate_batch_with_strategy
    decode_strategy.advance(log_probs, attn)
  File "c:\programdata\anaconda3\envs\nuecg\lib\site-packages\onmt\translate\beam_search.py", line 283, in advance
    rounding_mode='trunc')
TypeError: div() got an unexpected keyword argument 'rounding_mode'
```


Discussion:

`self._batch_index = torch.floor_divide(self.topk_ids, vocab_size)`
Yes the behavior changed in pytorch 1.9, we'll update the requirements to make sure people install a more recent version of Torch (1.6.0 is quite old)

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -21,7 +21,7 @@
     },
     python_requires=">=3.5",
     install_requires=[
-        "torch>=1.6.0",
+        "torch>=1.9.0",
         "torchtext==0.5.0",
         "configargparse",
         "tensorboard>=2.3",


Test patch:
Repository: jazzband/pip-tools

Issue:
Support Python versions lower than 2.7, too



Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -18,7 +18,7 @@
     #include_package_data=True,
     zip_safe=False,
     platforms='any',
-    #install_requires=[],
+    install_requires=['argparse==1.2.1'],  # needed for python 2.6
     classifiers=[
         # As from http://pypi.python.org/pypi?%3Aaction=list_classifiers
         #'Development Status :: 1 - Planning',


Test patch:
diff --git a/tests/dump-to-multiple-req-files.t b/tests/dump-to-multiple-req-files.t
--- a/tests/dump-to-multiple-req-files.t
+++ b/tests/dump-to-multiple-req-files.t
@@ -8,9 +8,13 @@ Setup:
 
   $ echo "times" > requirements.txt
   $ pip install -r requirements.txt >/dev/null 2>&1
-  $ echo "Flask\nWerkzeug\nJinja2" > more-requirements.txt
+  $ echo "Flask\nWerkzeug\nJinja2\n" > more-requirements.txt
   $ pip install -r more-requirements.txt >/dev/null 2>&1
 
+Install argparse so pip-dump works in Python 2.6
+
+  $ pip install argparse >/dev/null 2>&1
+
 Next, let's see what pip-dump does:
 
   $ pip-dump
@@ -18,6 +22,7 @@ Next, let's see what pip-dump does:
 It should've updated requirements.txt with pinned versions of all requirements:
 
   $ cat requirements.txt
+  argparse==* (glob)
   python-dateutil==* (glob)
   pytz==* (glob)
   six==* (glob)
diff --git a/tests/dump.t b/tests/dump.t
--- a/tests/dump.t
+++ b/tests/dump.t
@@ -9,6 +9,10 @@ Setup:
   $ echo "times" > requirements.txt
   $ pip install -r requirements.txt >/dev/null 2>&1
 
+Install argparse so pip-dump works in Python 2.6
+
+  $ pip install argparse >/dev/null 2>&1
+
 Next, let's see what pip-dump does:
 
   $ pip-dump
@@ -16,6 +20,7 @@ Next, let's see what pip-dump does:
 It should've updated requirements.txt with pinned versions of all requirements:
 
   $ cat requirements.txt
+  argparse==* (glob)
   python-dateutil==* (glob)
   pytz==* (glob)
   six==* (glob)
diff --git a/tests/review.t b/tests/review.t
--- a/tests/review.t
+++ b/tests/review.t
@@ -12,7 +12,11 @@ Also install library, which caused warning message:
 
   $ pip install http://www.effbot.org/media/downloads/cElementTree-1.0.5-20051216.tar.gz >/dev/null 2>&1
 
-Next, let's see what pip-dump does:
+Install argparse so pip-review works in Python 2.6
+
+  $ pip install argparse >/dev/null 2>&1
+
+Next, let's see what pip-review does:
 
   $ pip-review
   Warning: cannot find svn location for cElementTree==1.0.5-20051216
Repository: jazzband/pip-tools

Issue:
pip-review should compare version, not test equality
```
$ pip-review
pelican==3.0.1 is available (you have 3.1)
```

I'm locally testing this package, and `pip-review` will just test if current installed version is the same as the latest version in `pip`. Which causes problem as shown above.



Discussion:
Sounds like something comparable to #7. It's the advertised version on PyPI that has the ordering wrong. pip-tools only obeys PyPI as _it_ does the ordering, not pip-tools.

PyPI is correct in this case, the last pelican version is 3.0.1 and @yegle has a more recent version since it's a development build.

So the question is, should pip-review only test for greater versions available on PyPI? I'd be fine with it…

Yeah, I'd be fine with it, too. We should explicitly assume PEP386 compliance, then, though. But that's also a good thing to do anyway.

I am having the same problem with development packages. For Trac is reporting a more updated version 1.0, but it is wrong because I am using development version 1.0.1dev-r11409. Same for bzr (2.5.1) vs 2.6b2 or others.

<pre>
# pip-review --interactive
Warning: cannot find svn location for flup==1.0.3.dev-20110405
Warning: cannot find svn location for django-inlinetrans==0.4.12bdev-r70
Warning: cannot find svn location for Trac==1.0.1dev-r11409
PIL==1.1.6 is available (you have 1.1.7)
Upgrade now? [Y]es, [N]o, [A]ll, [Q]uit y
Downloading/unpacking PIL==1.1.6
  Could not find a version that satisfies the requirement PIL==1.1.6 (from versions: )
No distributions matching the version for PIL==1.1.6
Storing complete log in /root/.pip/pip.log
Trac==1.0 is available (you have 1.0.1dev-r11409)
Upgrade now? [Y]es, [N]o, [A]ll, [Q]uit n
bzr==2.5.1 is available (you have 2.6b2)
Upgrade now? [Y]es, [N]o, [A]ll, [Q]uit n
No update information found for django-compressor
No update information found for django-evolution
No update information found for filebrowser-safe
No update information found for grappelli-safe
No update information found for iotop
mimeparse==0.1.4 is available (you have 0.1.3)
Upgrade now? [Y]es, [N]o, [A]ll, [Q]uit y
Downloading/unpacking mimeparse==0.1.4
  Could not find a version that satisfies the requirement mimeparse==0.1.4 (from versions: )
No distributions matching the version for mimeparse==0.1.4
Storing complete log in /root/.pip/pip.log
No update information found for template-utils
</pre>

This issue makes that I cannot trust deeply in pip-review and I always have to run with --interactive

I'd be happy to accept a patch that implements this. The patch should add a
"pip_tools" package, which contains a NormalizedVersion, much like the
"future" branch already has (it can be copied from that branch literally).
Then, the implementation is easy.



Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -6,7 +6,7 @@
 
 
 def get_dependencies():
-    deps = []
+    deps = ['verlib']
     if sys.version_info < (2, 7):
         deps += ['argparse']
     return deps


Test patch:
Repository: jazzband/pip-tools

Issue:
pip-sync has no --find-links option
`pip-compile --find-links=some/dir/ requirements.in` isn't particularly useful if you can't then run `pip-sync --find-links=some/dir/ requirements.txt` to install dependencies from `some/dir/`.



Discussion:

Resolving patch:
diff --git a/piptools/scripts/sync.py b/piptools/scripts/sync.py
--- a/piptools/scripts/sync.py
+++ b/piptools/scripts/sync.py
@@ -25,8 +25,10 @@
 @click.command()
 @click.option('--dry-run', is_flag=True, help="Only show what would happen, don't change anything")
 @click.option('--force', is_flag=True, help="Proceed even if conflicts are found")
+@click.option('-f', '--find-links', multiple=True, help="Look for archives in this directory or on this HTML page", envvar='PIP_FIND_LINKS')  # noqa
+@click.option('--no-index', is_flag=True, help="Ignore package index (only looking at --find-links URLs instead)")
 @click.argument('src_files', required=False, type=click.Path(exists=True), nargs=-1)
-def cli(dry_run, force, src_files):
+def cli(dry_run, force, find_links, no_index, src_files):
     if not src_files:
         if os.path.exists(DEFAULT_REQUIREMENTS_FILE):
             src_files = (DEFAULT_REQUIREMENTS_FILE,)
@@ -56,4 +58,11 @@ def cli(dry_run, force, src_files):
     installed_dists = pip.get_installed_distributions()
     to_install, to_uninstall = sync.diff(requirements, installed_dists)
 
-    sys.exit(sync.sync(to_install, to_uninstall, verbose=True, dry_run=dry_run))
+    pip_flags = []
+    for link in find_links or []:
+        pip_flags.extend(['-f', link])
+    if no_index:
+        pip_flags.append('--no-index')
+
+    sys.exit(sync.sync(to_install, to_uninstall, verbose=True, dry_run=dry_run,
+                       pip_flags=pip_flags))
diff --git a/piptools/sync.py b/piptools/sync.py
--- a/piptools/sync.py
+++ b/piptools/sync.py
@@ -116,14 +116,14 @@ def diff(compiled_requirements, installed_dists):
     return (to_install, to_uninstall)
 
 
-def sync(to_install, to_uninstall, verbose=False, dry_run=False):
+def sync(to_install, to_uninstall, verbose=False, dry_run=False, pip_flags=[]):
     """
     Install and uninstalls the given sets of modules.
     """
     if not to_uninstall and not to_install:
         click.echo("Everything up-to-date")
 
-    pip_flags = []
+    pip_flags = pip_flags[:]
     if not verbose:
         pip_flags.append('-q')
 


Test patch:
Repository: jazzband/pip-tools

Issue:
pip-compile looses `via` with pip 8
```
$ echo jinja2 > req
$ pip-compile --version
pip-compile, version 1.5
$ pip --version
pip 7.1.2 from <snip>lib/python2.7/site-packages (python 2.7)

pip-compile req
#
# This file is autogenerated by pip-compile
# Make changes in req, then run this to update:
#
#    pip-compile req
#

jinja2==2.8
markupsafe==0.23          # via jinja2

$ pip install -U pip
<snip>

$ pip --version
pip 8.0.2 from <snip>lib/python2.7/site-packages (python 2.7)

pip-compile req
#
# This file is autogenerated by pip-compile
# Make changes in req, then run this to update:
#
#    pip-compile req
#

jinja2==2.8
MarkupSafe==0.23
```

note the missing `via jinja2` for pip 8



Discussion:

Resolving patch:
diff --git a/piptools/writer.py b/piptools/writer.py
--- a/piptools/writer.py
+++ b/piptools/writer.py
@@ -95,7 +95,7 @@ def _format_requirement(self, ireq, reverse_dependencies, primary_packages, incl
             return line
 
         # Annotate what packages this package is required by
-        required_by = reverse_dependencies.get(ireq.name, [])
+        required_by = reverse_dependencies.get(ireq.name.lower(), [])
         if required_by:
             line = line.ljust(24)
             annotation = ', '.join(sorted(required_by))


Test patch:
diff --git a/tests/test_writer.py b/tests/test_writer.py
--- a/tests/test_writer.py
+++ b/tests/test_writer.py
@@ -32,6 +32,16 @@ def test_format_requirement_annotation(from_line, writer):
             'test==1.2               ' + comment('  # via xyz'))
 
 
+def test_format_requirement_annotation_case_sensitive(from_line, writer):
+    ireq = from_line('Test==1.2')
+    reverse_dependencies = {'test': ['xyz']}
+
+    assert (writer._format_requirement(ireq,
+                                       reverse_dependencies,
+                                       primary_packages=[]) ==
+            'Test==1.2               ' + comment('  # via xyz'))
+
+
 def test_format_requirement_not_for_primary(from_line, writer):
     "Primary packages should not get annotated."
     ireq = from_line('test==1.2')
Repository: jazzband/pip-tools

Issue:
Extras not propagated into requirements.txt after insertion
Extras, in this context, are specific functional extensions to a particular package.

This is similar to #154 but differs because this triggers when adding an extra to an existing requirement.

The cached result appears to prevent appropriate detection that the extra was added.

##### Steps to replicate

1. Create a `requirements.in` as follows:
  ```text
pip-tools
hypothesis
   ```
2. Run `pip-compile` from the command line.
3. Edit the requirements.in file to the following:
  ```text
pip-tools
hypothesis[django]
  ```
4. Re-run `pip-compile` from the command line.
3. Examine `requirements.txt`

##### Expected result

```text
#
# This file is autogenerated by pip-compile
# To update, run:
#
#    pip-compile --output-file reqs.txt reqs.in
#
click==6.6                # via pip-tools
django==1.10.3            # via hypothesis
fake-factory==0.7.2       # via hypothesis
first==2.0.1              # via pip-tools
hypothesis[django]==3.6.0
pip-tools==1.7.0
python-dateutil==2.6.0    # via fake-factory
pytz==2016.7              # via hypothesis
six==1.10.0               # via fake-factory, pip-tools, python-dateutil
```

##### Actual result

```text
#
# This file is autogenerated by pip-compile
# To update, run:
#
#    pip-compile --output-file reqs.txt reqs.in
#
click==6.6                # via pip-tools
first==2.0.1              # via pip-tools
hypothesis==3.6.0
pip-tools==1.7.0
six==1.10.0               # via pip-tools
```

##### Workaround

Simply deleting the existing `requirements.txt` file and installing from scratch appears to work, but shouldn't be a necessary part of the pip-tools workflow.


Discussion:

Resolving patch:
diff --git a/piptools/repositories/local.py b/piptools/repositories/local.py
--- a/piptools/repositories/local.py
+++ b/piptools/repositories/local.py
@@ -2,7 +2,7 @@
 from __future__ import (absolute_import, division, print_function,
                         unicode_literals)
 
-from piptools.utils import key_from_req
+from piptools.utils import as_tuple, key_from_req, make_install_requirement
 from .base import BaseRepository
 
 
@@ -57,7 +57,10 @@ def find_best_match(self, ireq, prereleases=None):
         key = key_from_req(ireq.req)
         existing_pin = self.existing_pins.get(key)
         if existing_pin and ireq_satisfied_by_existing_pin(ireq, existing_pin):
-            return existing_pin
+            project, version, _ = as_tuple(existing_pin)
+            return make_install_requirement(
+                project, version, ireq.extras
+            )
         else:
             return self.repository.find_best_match(ireq, prereleases)
 


Test patch:
Repository: jazzband/pip-tools

Issue:
Providing a source file which does not have an extension writes to a .txt file in current dir
If you happen to use an extensionless filename as a source of requirements in, pip-compile will deduce the wrong output filename and generate a ".txt" file (relative file, thus at current working dir).

##### Environment Versions

1. OS Type Should be cross platform, but observed on Windows
1. Python version: `$ python -V` 2.7.8
1. pip version:  `$ pip --version` 9.0.1
1. pip-tools version: `$ pip-compile --version` 1.8.1rc2

##### Steps to replicate

1. echo "request" > no_extension
2. pip-compile no_extension

##### Expected result

We should error out because it is difficult to deduce a new name if there is no extension to remove.

##### Actual result

a .txt file is generated at the current directory.



Discussion:
Giving an error is an option, but how about simply adding ".txt" for the output filename , as it's already the used extension for the output file.
Ex:
pip-compile no_extension
Result: no_extension.txt is created, containing the pip-compile output.

That way, if anyone happens to be using files without extension as input, it won't break them, while not outputing to exact same file for every filename without extension, which is the case right now.
@vphilippon yes, you are right, appending .txt to a filename missing extension is the simple solution.

Resolving patch:
diff --git a/piptools/scripts/compile.py b/piptools/scripts/compile.py
--- a/piptools/scripts/compile.py
+++ b/piptools/scripts/compile.py
@@ -92,7 +92,7 @@ def cli(verbose, dry_run, pre, rebuild, find_links, index_url, extra_index_url,
     if output_file:
         dst_file = output_file
     else:
-        base_name, _, _ = src_files[0].rpartition('.')
+        base_name = src_files[0].rsplit('.', 1)[0]
         dst_file = base_name + '.txt'
 
     if upgrade and upgrade_packages:


Test patch:
diff --git a/tests/test_cli.py b/tests/test_cli.py
--- a/tests/test_cli.py
+++ b/tests/test_cli.py
@@ -219,3 +219,21 @@ def test_editable_package(tmpdir):
         assert out.exit_code == 0
         assert fake_package_dir in out.output
         assert 'six==1.10.0' in out.output
+
+
+def test_input_file_without_extension(tmpdir):
+    """
+    piptools can compile a file without an extension,
+    and add .txt as the defaut output file extension.
+    """
+    runner = CliRunner()
+    with runner.isolated_filesystem():
+        with open('requirements', 'w') as req_in:
+            req_in.write('six==1.10.0')
+
+        out = runner.invoke(cli, ['-n', 'requirements'])
+
+        print(out.output)
+        assert out.exit_code == 0
+        assert '--output-file requirements.txt' in out.output
+        assert 'six==1.10.0' in out.output
Repository: jazzband/pip-tools

Issue:
README broken on PyPI (must be reStructuredText)
The [package description](https://pypi.python.org/pypi/pip-tools/) on PyPI is unreadable since PyPI expects the README in [reStructuredText](http://www.sphinx-doc.org/en/stable/rest.html) file format and we use MarkDown.

Solution A: Convert to reST
---------------------

1. Rename the current `README.md` to `README.rst`
1. Replace the markdown of the badges and the code samples ([example](https://github.com/Organice/djangocms-maps/blob/master/README.rst))
1. Add a `long_description=read_file('README.rst')` line to `setup.py` ([example](https://github.com/Organice/djangocms-maps/blob/master/setup.py#L50))

Solution B: Process before Upload
-------------------

1. Integrate [pypandoc](https://pypi.python.org/pypi/pypandoc) in `setup.py` ([example](https://github.com/jrief/djangocms-cascade/blob/master/setup.py#L7-L14))
1. Add a `long_description=convert('README.md', 'rst')` line to `setup.py` ([example](https://github.com/jrief/djangocms-cascade/blob/master/setup.py#L49))

------------

Both solutions above will render a nicely formatted, HTML-styled package description on PyPI.

Quality Assurance
--------------

Optionally, you may check your README with [checkdocs](https://github.com/Organice/djangocms-maps/blob/master/tox.ini#L13-L19) before uploading the package to PyPI, because sometimes the reST-to-HTML conversion that PyPI uses fails -- and renders a still hard-to-read, broken, unformatted package description.


Discussion:
Let me know if you want this to be fixed, and which solution you prefer. I can happily prepare a PR.
Hi @bittner, thanks for the report and suggestions.

I would suggest to go with A). Mostly because:
> Pypandoc uses pandoc, so it needs an available installation of pandoc. 

and there are no prebuilt wheels for Linux with `pandoc`, so that could be an issue with the BMs for the releases. Let's just keep the release process as simple as possible, especially in the Jazzband context :p. (But thank you for the info, I might use that in my own projects) 

Thanks again, you can submit a PR, that would be really appreciated!

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -1,8 +1,14 @@
 """
 pip-tools keeps your pinned dependencies fresh.
 """
+from os.path import abspath, dirname, join
 from setuptools import find_packages, setup
 
+def read_file(filename):
+    """Read the contents of a file located relative to setup.py"""
+    with open(join(abspath(dirname(__file__)), filename)) as thefile:
+        return thefile.read()
+
 setup(
     name='pip-tools',
     use_scm_version=True,
@@ -11,6 +17,7 @@
     author='Vincent Driessen',
     author_email='me@nvie.com',
     description=__doc__,
+    long_description=read_file('README.rst'),
     packages=find_packages(exclude=['tests']),
     setup_requires=['setuptools_scm'],
     install_requires=[


Test patch: