a-better-finder-attributes: move to a/a-better-finder-attributes

[cho-m]

Important: Do not tick a checkbox if you haven’t performed its action. Honesty is indispensable for a smooth review process.

In the following questions <cask> is the token of the cask you're submitting.

After making any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online <cask> is error-free.
• brew style --fix <cask> reports no offenses.

Additionally, if adding a new cask:

• Named the cask according to the token reference.
• Checked the cask was not already refused.
• Checked the cask is submitted to the correct repo.
• brew audit --new-cask <cask> worked successfully.
• brew install --cask <cask> worked successfully.
• brew uninstall --cask <cask> worked successfully.

---

Experimenting with moving single cask to shard.

I think it will fail style assuming CI runs:

❯ brew style a-better-finder-attributes
a/a-better-finder-attributes.rb:1:1: C: [Correctable] Missing frozen string literal comment.
cask "a-better-finder-attributes" do
^

1 file inspected, 1 offense detected, 1 offense autocorrectable

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[p-linnane]

@cho-m Do we still need this open?

[cho-m]

We should figure out how to shard the repo. I think we will want to commit at least one cask to test with before a full migration, whether this one or another option (3rd check item below).

Some things that may need to be done:

• Agree on sharding approach, e.g. the a/ - z/ directories? leave [0-9].* casks alone or also use 0/ directory? etc.
• I mentioned on Slack some URLs that won't work for any Cask we migrate. Not sure if we want to handle before or just leave them broken (assuming low impact), e.g.
  • https://github.com/Homebrew/brew/blob/master/Library/Homebrew/api.rb#L123 (we could still migrate with this broken as I think it will take the fallback using formulae.brew.sh)

          raw_endpoint = "#{git_head}/Casks/#{name}.rb"

  • https://github.com/Homebrew/formulae.brew.sh/blob/master/_layouts/cask.html#L23 (I think this is only used for website)

    <p><a target="_blank" href="{{ site.taps.cask.remote }}/blob/{{ c.tap_git_head }}/Casks/{{ token }}.rb">Cask code</a> on GitHub</p>

• Commit a small number of Cask migrations to test everything is working, e.g. API installs
• Potential mass migration or migrate in phases. EDIT: May also do history rewrite at same time? Not sure how we were planning to handle this as would probably be impacting to non-API users.
• Add some checks, e.g. new Casks should be in correct shard.

[reitermarkus]

I have tried a few sharding approaches, but haven't found a definitive one yet. These two seem like the best ones far.

Approach 1

In order to not have any hotspots with directories that are huge, we'd probably need to have dynamically sized shards, i.e. start with a/, and if a/ grows too large, add a second letter and move all casks into the next level a/{a-z0-9}/.

Approach 2

Use first and last letter. Currently, the biggest directory using this approach (sr/) would contain 63 casks, which I think is acceptable. This also avoids having paths containing - (i.e. a/-/a-better-finder-attributes.rb in approach 1), which look a bit weird.

[carlocab]

Just testing something. Feel free to ignore.

[razvanazamfirei]

@reitermarkus, approach 2 makes a lot of sense to me. Last I checked, we would end up with ~500 directories.

I've been playing around with md5 hashing the file name and taking a modulo of the hash to control the number of directories. If we use it to assign cask to directories, the distribution of casks/shard is reasonable. It would be decently easy to implement and audit, but very user-unfriendly.

[MikeMcQuaid]

Use first and last letter. Currently, the biggest directory using this approach (sr/) would contain 63 casks, which I think is acceptable. This also avoids having paths containing - (i.e. a/-/a-better-finder-attributes.rb in approach 1), which look a bit weird.

First and last letter seems weird to me. Better to do first and second letter IMO and can treat symbols differently e.g. skip them, put them into the directory without, etc.

If we use it to assign cask to directories, the distribution of casks/shard is reasonable. It would be decently easy to implement and audit, but very user-unfriendly.

Agreed. This is too user unfriendly.

Note: even sharding by a-z will be a noted improvement on what we have today. For Homebrew/homebrew-core we're likely to do something like:

>> h={};CoreTap.instance.formula_names.each {|f| key = f[0]; key = "lib" if f.start_with?("lib"); h[key] ||= []; h[key] << f }; nil; h.each_key {|k| puts "#{k}: #{h[k].size}" }; nil
a: 330
b: 244
c: 509
d: 303
e: 148
f: 249
g: 523
h: 158
i: 155
j: 130
k: 126
l: 216
lib: 487
m: 386
n: 201
o: 209
p: 454
q: 59
r: 232
s: 536
t: 311
u: 83
v: 126
w: 129
x: 104
y: 51
z: 75

which gets us reasonable levels of balance (none under 50, none over 550).

[razvanazamfirei]

/rebase

[p-linnane]

Closing this out now that sharding was completed in #152603.