[FR]: Add utillities from bzlparty/lib_common

[mgred]

What is the current behavior?

No response

Describe the feature

This is a proposal to add some/all functions from bzlparty/lib_common. The motivation comes from this conversation. I follow @alexeagle advice to propose the code as a new feature to collect everybody's opinion and perspective.

My personal motivation was to have a place to collect generic functions I found useful while writing rulesets.

@kormide I was told that you have done a lot of work regarding the public API and maybe could help integrating the functionality.

I would love to work with you guys and hear what you have to say.

I totally appreciate any feedback and opinion on this

[alexeagle]

1. Xudong has good feedback on that BCR PR that we should consider whether the syntax sugar is worth it, vs. using the starlark language directly.

the readability of any code that potentially depends on it

For example your

occurs(2, [1, 2, 3]) // True
occurs("foo", ["bar", "baz"]) // False

should probably be written

2 in [1, 2, 3] # True
"foo" in ["bar", "baz"] # False

And I think len(filter(f, arr)) == 1 is easier to read than once(f, arr) especially since it allows for expressing "exactly two matching elements"

2. Other than occurs your lib is basically functional programming idioms that are possible thanks to the addition of lambda to the language. Maybe it could be functions.bzl or lambdas.bzl

3. We should nitpick the names from whether there's a popular idiom for python developers, so we don't accidentally introduce more differences between that and starlark

4. We should figure out a place to "dogfood" this so we have the experience of being a user of the new API. Maybe we can refactor other code in bazel-lib to use these.

[mgred]

Thanks for your feedback @alexeagle

1. Xudong has good feedback on that BCR PR that we should consider whether the syntax sugar is worth it, vs. using the starlark language directly.

the readability of any code that potentially depends on it

For example your

occurs(2, [1, 2, 3]) // True
occurs("foo", ["bar", "baz"]) // False

should probably be written

2 in [1, 2, 3] # True
"foo" in ["bar", "baz"] # False

Good point 👍 Using the in operator is definitely the better choice here and also common in Python and TS/JS. So I think occurs can be dropped 😄

And I think len(filter(f, arr)) == 1 is easier to read than once(f, arr) especially since it allows for expressing "exactly two matching elements"

True, a comparison like len(filter(f, arr)) == n gives more flexibility but may be overloaded in common cases e.g.: if empty(["foo", "bar"]) or if is_empty(["foo", "bar"]) is more fluid to read and write than always the same comparison. At least to me 😝

2. Other than occurs your lib is basically functional programming idioms that are possible thanks to the addition of lambda to the language. Maybe it could be functions.bzl or lambdas.bzl

I imagine loading a function like load("@aspect_bazel_lib//lib:functions.bzl", "..."), and would expect this function does something with functions. All methods currently operate on lists, wouldn't it be clearer to name it after the data type it works on, like lists.bzl in this case?

3. We should nitpick the names from whether there's a popular idiom for python developers, so we don't accidentally introduce more differences between that and starlark

The naming is very much inspired by JS array functions. Making it more compatible/similar to python is obvious as you pointed out 👍

4. We should figure out a place to "dogfood" this so we have the experience of being a user of the new API. Maybe we can refactor other code in bazel-lib to use these.

Yep 👍

[alexeagle]

lists.bzl sounds right to me. @thesayyn any opinions on this one?

[alexeagle]

I think this is ready to implement, @mgred if you find time and interest to send a PR I'll make sure we get it merged

[mgred]

@alexeagle

alright, i'll send a PR within the next days.. then we can finetune from there

[mgred]

I close this issue because #512 was merged