Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve formatting of long "via" annotations #1237

Merged
merged 5 commits into from
Nov 26, 2020
Merged

Improve formatting of long "via" annotations #1237

merged 5 commits into from
Nov 26, 2020

Conversation

jdufresne
Copy link
Member

When there is more than one "via" annotation, they are now formatted one
per line. This prevents very long lines in requirements.txt output. The
very long lines often scroll beyond the width of an editor, making them
difficult to read. Worse, when these annotations change, diffs are hard
to read as the actual difference is hidden far off to the right. By
placing one annotation per line, diffs will be much more obvious. This
follows the philosophy of many automatic formatters such as Black.

To simplify the formatting and to make it more consistent, annotations
are now always on the line after the requirement, whether hashes were
generated or not.

Fixes #1036

Contributor checklist
  • Provided the tests for the changes.
  • 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).

@jdufresne jdufresne added this to the 5.5.0 milestone Nov 22, 2020
setup.cfg Outdated Show resolved Hide resolved
@atugushev
Copy link
Member

Looks nice! I wonder what @vphilippon would think?

@atugushev atugushev added enhancement Improvements to functionality writer Related to results output writer component annotations Related to packages annotations labels Nov 25, 2020
@vphilippon
Copy link
Member

vphilippon commented Nov 26, 2020

I like that!
I might even prefer it with comas, like:

            # via
            #   -r requirements.in,
            #   django-debug-toolbar,
            #   django-storages,
            #   django-taggit,
            #   djangorestframework

(',\n'.join(...))
I feel like it helps me spot it as an ongoing list quickly.
But that's really a preference, not a blocker or game changer.

Beside that, 👍 from me!

Edit: I wrote the coma suggestion without actually thinking about the potential risk of adding some git diff conflict with that. I'll let you be the judge of that :)

@jdufresne
Copy link
Member Author

My preference is for no comma. IMO, it doesn't add much to the formatting and I think the no-comma result looks clean and readable enought without it.

I wrote the coma suggestion without actually thinking about the potential risk of adding some git diff conflict with that. I'll let you be the judge of that :)

This is also a concern for me. When the last dependency in the list changes, now two lines will change instead of one. this causes unnecessary diff noise. So another reason I prefer no comma.

I don't consider the above too big a deal though, so if it is considered a blocker, let me know and I'll change it.

@graingert
Copy link
Member

graingert commented Nov 26, 2020

from my issue #1036 the version with commas:

    # via automat
    #   , bcrypt
    #   , cryptography
    #   , ecdsa
    #   , format-cef
    #   , grpcio
    #   , patchy
    #   , pathlib
    #   , prompt-toolkit
    #   , protobuf
    #   , pyhamcrest

But I think this PR resolves all the problems I was having with the single line via so I'm happy with or without (leading) commas

@graingert
Copy link
Member

looking at the test output again, I really like how it looks, and I think I prefer comma-less

@atugushev
Copy link
Member

@vphilippon thanks for your feedback!

I like also "no comma" annotations. Less diff and less symbols.

Copy link
Member

@atugushev atugushev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

Copy link
Member

@vphilippon vphilippon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍
Agreed on the coma-less format then, I'm a-ok with that!

Makes for more robust tests as the complete output is tested. Helps show
and catch subtle or unexpected changes in output.
Some of the test data exceeds the 88 width limit, so this has been
bumped to 100. Black will continue to format non-string statements at a
max width of 88.
The pip requirement does not continue on the next line so the line
should not end in a trailing slash.
This makes the annotation output more consistent. No longer place
annotations inline when hashes aren't generated. Now, always place
annotations on a new line. When the annotation comment is very long,
this helps make the result more readable as it is less likely to
continue far off to the right.
When there is more than one "via" annotation, they are now formatted one
per line. This prevents very long lines in requirements.txt output. The
very long lines often scroll beyond the width of an editor, making them
difficult to read. Worse, when these annotations change, diffs are hard
to read as the actual difference is hidden far off to the right. By
placing one annotation per line, diffs will be much more obvious. This
follows the philosophy of many automatic formatters such as Black.

To simplify the formatting and to make it more consistent, annotations
are now always on the line after the requirement, whether hashes were
generated or not.

Fixes #1036
@jdufresne
Copy link
Member Author

Thanks for the feedback and reviews all!

@jdufresne jdufresne merged commit 79bc8c6 into jazzband:master Nov 26, 2020
@jdufresne jdufresne deleted the hashes-annotations branch November 26, 2020 18:38
@scholarsmate
Copy link

FYI, this new formatting breaks the requirements-txt-fixer pre-commit hook.

@adamchainz
Copy link
Contributor

@jdufresne Just upgraded and love this change, thanks!

@rsalmaso
Copy link

rsalmaso commented Jan 4, 2021

This is a breaking change... And broke my workflow 😞

@webknjaz
Copy link
Member

webknjaz commented Jan 4, 2021

This is a breaking change... And broke my workflow

Sounds like a reference to
XKCD Workflow comic #1172

@@ -63,7 +63,7 @@ markers =
network: mark tests that require internet access

[flake8]
max-line-length = 88
max-line-length = 100
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this looks like a bad standard :(

@webknjaz
Copy link
Member

webknjaz commented Jan 4, 2021

FYI, this new formatting breaks the requirements-txt-fixer pre-commit hook.

Sounds like this should've been a CLI flag and not an opinionated reformatting

@bendikro
Copy link
Contributor

bendikro commented Jan 4, 2021

FYI, this new formatting breaks the requirements-txt-fixer pre-commit hook.

Sounds like this should've been a CLI flag and not an opinionated reformatting

Obviously. There are always good reasons to make changes, but the very good reasons not to make changes are often ignored. Such as you will probably be breaking something.

This was referenced Mar 15, 2021
jnm added a commit to kobotoolbox/kobocat that referenced this pull request May 25, 2021
Includes a humongous diff thanks to jazzband/pip-tools#1237, which
places each "via" package on a separate line
jnm added a commit to kobotoolbox/kobocat that referenced this pull request May 25, 2021
Includes a humongous diff thanks to jazzband/pip-tools#1237, which
places each "via" package on a separate line
@belm0
Copy link

belm0 commented Jun 2, 2021

The rendered formatting of requirements.txt is not a stable API. It is expected to be correct and informative, but wasn't built specifically to be consumed by other tools. So I disagree with the assertion that this is a breaking change.

Given that it's normal to commit requirements.txt files into a project repo (that's how you pin, after all), it's more than a matter of breaking tools trying to consume the file. Suddenly we have a large diff in our project's requirements.txt since the file is entirely rewritten, and we'd like to decide when to incur that diff (e.g. by way of a friendly command line option for this formatting change) rather than have the timing be imposed upon us.

As with any other dependency, I recommend pinning pip-tools within your project.

Except, your project may need Python 3.9 support or other features which are orthogonal to this formatting change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
annotations Related to packages annotations enhancement Improvements to functionality writer Related to results output writer component
Projects
None yet
Development

Successfully merging this pull request may close these issues.

via lines often result in git conflict