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

Add option to sort lists by default #833

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

davidhao3300
Copy link

We work in a repo that does not care about dependency order, and we keep our lists in variables. A simple example of a typical file in our repo looks like:

DEPS = [
    ":a"',
    ":b",
    ":c",
]
function_call(deps=DEPS)

We'd like to keep lists sorted by default, and if we ever have a case of wanting to preserve order, we can choose to use the "do not sort" comment.

This PR adds an option to sort by lists by default, and it respects the existing "do not sort" comment.

@googlebot
Copy link

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.


What to do if you already signed the CLA

Individual signers
Corporate signers

ℹ️ Googlers: Go here for more info.

@@ -450,7 +456,7 @@ func sortStringList(x Expr, context string) {
return
}

forceSort := keepSorted(list) || keepSorted(list.List[0])
forceSort := forceKeepSorted(list) || forceKeepSorted(list.List[0])
Copy link
Author

Choose a reason for hiding this comment

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

this bit of logic requires users to explicitly comment "keep sorted" on lists with comments

@davidhao3300
Copy link
Author

@googlebot I signed it!

@googlebot
Copy link

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

@pmbethe09
Copy link
Member

what problem does this solve that some combination of:
tables.go and jsontables doesn't already solve in combo with # buildifier: do not sort

?

@davidhao3300
Copy link
Author

my understanding is that the code block

DEPS = [
    ":a"',
    ":b",
    ":c",
]

is handled by some subset of the following lines: https://github.com/bazelbuild/buildtools/blob/master/build/rewrite.go#L411-L434
These branches will only sort the list only if the list is prepended with a comment saying "keep sorted". In the current state, we would have to prepend every list with that comment, which is not ideal for us.

@davidhao3300
Copy link
Author

I'm not familiar with what jsontables is, and google doesn't seem to be returning relevant results. What is that?

@laurentlb
Copy link
Contributor

It's correct, this is currently not supported.

However, I feel like this is a very niche need and it doesn't match the style recommendations in Bazel. I would encourage you to build your own program (using Buildifier as a library) to perform this transformation; you'll just need to write a few lines of Go. I don't think this feature should belong to Buildifier.

@davidhao3300
Copy link
Author

davidhao3300 commented May 15, 2020

Based on https://docs.bazel.build/versions/master/skylark/build-style.html, it's true that we should Prefer to list dependencies directly, as a single list. Putting the “common” dependencies of several targets into a variable reduces maintainability, makes it impossible for tools to change the dependencies of a target and can lead to unused dependencies.
I'd push back and say that the style guide doesn't forbid the general idea of putting lists in variables, so I think there would be use for others who may keep lists in variables for whatever reason?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants