Ensure pip-compile --no-header <blank requirements.in> creates/overwrites requirements.txt

[AndydeCleyre]

Before, in the case where the writer should generate a blank output document (e.g. requirements.txt), no new file would be created, and any existing file with that name would be left unchanged. With this change, a blank document will created and overwritten if it exists.

This is implemented by having the writer keep track of whether it yields any lines, and if not, yielding an empty string (where before it would yield nothing).

A simpler solution would be to always yield an extra empty string at the end of _iter_lines, but that would result in a bit of awkward space at the bottom of all the txts, and if that were fixed it would involve leaking the composition logic outside of _iter_lines.

Changelog-friendly one-liner: pip-compile --no-header <blank requirements.in> now creates/overwrites requirements.txt.

Fixes #900.

@atugushev I hereby request a review. If this does not satisfy the "Requested a review from another contributor" requirement, please tell me what does. Thanks!

Contributor checklist

• Provided the tests for the changes.
• Requested a review from another contributor.
• Gave a clear one-line description in the PR (that the maintainers can add to CHANGELOG.md on release).
• Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

[atugushev]

Thank you for submitting this! I was thinking about:

@@ -230,6 +220,10 @@ class OutputWriter(object):
             if not self.dry_run:
                 self.dst_file.write(unstyle(line).encode("utf-8"))
                 self.dst_file.write(os.linesep.encode("utf-8"))
+        else:
+            # Create an empty file, if there is no output
+            if not self.dry_run:
+                self.dst_file.write("")

What do you think?

[atugushev]

@AndydeCleyre could you please rebase onto master to fix red CI checks?

[codecov]

Codecov Report

Merging #909 into master will decrease coverage by 0.47%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #909      +/-   ##
==========================================
- Coverage   99.06%   98.58%   -0.48%     
==========================================
  Files          35       35              
  Lines        2247     2264      +17     
  Branches      288      290       +2     
==========================================
+ Hits         2226     2232       +6     
- Misses         13       21       +8     
- Partials        8       11       +3

Impacted Files	Coverage Δ
tests/test_cli_compile.py	100% <100%> (ø)	⬆️
piptools/writer.py	99.2% <100%> (+0.05%)	⬆️
piptools/repositories/pypi.py	91.21% <0%> (-3.91%)	⬇️
piptools/utils.py	97.95% <0%> (-2.05%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 25a4e99...d53d3ff. Read the comment docs.

[AndydeCleyre]

Is a simple merge of master into here acceptable? GitHub pull requests don't love history rewrites.

I may be misunderstanding your alternative suggested fix, but:

1. If that's an else component of the for loop, that empty string would be written whenever the for loop finishes without interruption from a break statement, which would be every time, as there are no break statements. So the simpler version of this solution would be to add the extra dry run check and blank-write before the for loop.

2. While that will work, I thought changing the behavior of _iter_lines would be a less fragile solution, as it doesn't create a difference between what _iter_lines yields and what write produces, noting that _iter_lines is used directly by three existing tests.

That said, always writeing an empty string is simpler, and I'm happy to create a replacement pull request with that, cherry picking the commit from here which adds the test, and double-checking that other tests are not broken.

[atugushev]

My suggestion was wrong, thanks for noticing. I'm okay with the current approach, but I have a few comments.

[atugushev]

LGTM 👍

[atugushev]

Could you rebase and squash before I merge this pull request?

[atugushev]

Thanks, @AndydeCleyre!