1kc-razer: rename to razer-unofficial

[miccal]

https://github.com/orgs/Homebrew/discussions/4967

https://docs.brew.sh/Cask-Cookbook#special-affixes

[bevanjkay]

Is this an official application? It looks like the prefix is due to it being unofficial.

Calling this razer is likely misleading, as it would indicate that it is created by Razer.

[0xdevalias]

Is this an official application? It looks like the prefix is due to it being unofficial.

Calling this razer is likely misleading, as it would indicate that it is created by Razer.

It's not official; see my exploration RE: naming here:

• https://github.com/orgs/Homebrew/discussions/4967

tl;dr I think it may have been renamed with the 'fork prefix' incorrectly; and it feels like either razer-unofficial; or better yet, the actual app name as marketed: razer-macos

[SMillerDev]

tl;dr I think it may have been renamed with the 'fork prefix' incorrectly; and it feels like either razer-unofficial; or better yet, the actual app name as marketed: razer-macos

razer-unofficial is fine if it doesn't conflict, but razer-macos is just as confusing while also going against our token guidelines.

[0xdevalias]

razer-unofficial is fine if it doesn't conflict, but razer-macos is just as confusing while also going against our token guidelines.

@SMillerDev By my read of the token guidelines it says that the suffix is ok if it's an inherent part of the product name; and it wouldn't make sense if it was removed.

That's what I was basing my above suggestion on; as the app is specifically "Razer macOS"; it's not a fork/port of Razer from another platform.

I'd still be happier with razer-unofficial more than 1kc-razer though if there is zero chance of the -macos suffix to match the product name.

[bevanjkay]

@0xdevalias The token reference essentially suggests that where the token would be misleading you would first try to add a vendor prefix, and failing that would then add an -unofficial suffix.

https://docs.brew.sh/Cask-Cookbook#special-affixes

In this case I would suggest that 1kc-razer is the ideal token as it shows that it is an app called Razer developed by 1kc.

[bevanjkay]

I would suggest that the correct solution here is not changing the token but that brew search returns correct results including the name stanza.

According to brew search --help a casks name is only included in the search if you pass the --desc flag. So there is potentially room for improvement here. There is an existing issue in Homebrew/brew discussing handling searching of descriptions better, so noting this there could be helpful.

• upon testing this last thought, it does seem to be functioning incorrectly, which is still a separate issue to this PR.

[SMillerDev]

Searching "razer" on https://formulae.brew.sh does surface this cask first.

[0xdevalias]

In this case I would suggest that 1kc-razer is the ideal token as it shows that it is an app called Razer developed by 1kc.

@bevanjkay It's technically an app called "Razer macOS", not "Razer"; developed by 1kc.

I would suggest that the correct solution here is not changing the token but that brew search returns correct results including the name stanza.

@bevanjkay That would be ideal; as I'm sure this isn't the only cask that won't be easily searchable by its canonical name with the current limitations/bugs in the default search.

According to brew search --help a casks name is only included in the search if you pass the --desc flag. So there is potentially room for improvement here.

@bevanjkay Agreed.

There is an existing issue in Homebrew/brew discussing handling searching of descriptions better, so noting this there could be helpful.

@bevanjkay Are you able to link the relevant issue? If not I'll try and remember to find it when on a computer.

Searching "razer" on https://formulae.brew.sh does surface this cask first.

@SMillerDev Fair; but that's not how I (and I suspect many others) search: from the terminal.

[bevanjkay]

The standard here is that we would use the vendor prefix, unless that doesn't achieve any less ambiguity.

So I still believe that token should remain 1kc-razer.

https://docs.brew.sh/Acceptable-Casks#forks-and-apps-with-conflicting-names

[miccal]

I am done wasting my time dealing with this.

[bevanjkay]

@0xdevalias Thank you for your in-depth analysis of the situation here - https://github.com/orgs/Homebrew/discussions/4967

Regarding the issue in Homebrew/brew that could be somewhat related - Homebrew/brew#16237
Parsing the name text (and desc text, as plain text) may help in this situation. But I would suggest that perhaps consideration could be given to including the name by default in brew search or adding a separate flag, as requiring the use of --desc to search the name is not immediately apparent.

[0xdevalias]

The standard here is that we would use the vendor prefix, unless that doesn't achieve any less ambiguity.

So I still believe that token should remain 1kc-razer.

docs.brew.sh/Acceptable-Casks#forks-and-apps-with-conflicting-names

@bevanjkay It may just be that the way those docs are written is a little ambiguous, but it seems to be 2 different cases, merged into one (which is what I was trying to say earlier about it not being a fork (Ref)):

1. Forks must have the vendor’s name as a prefix...

2. For unrelated apps that share a name, the most popular one (usually the one already present) stays unprefixed. Since this can be subjective, if you disagree with a decision, open an issue and make your case to the maintainers.

As for my suggestion of keeping the -macOS suffix (Ref), it was based on the 'exception to the rule' in this part:

• https://docs.brew.sh/Cask-Cookbook#finding-the-simplified-name-of-the-vendors-distribution

  • Remove from the end: strings such as “Mac”, “for Mac”, “for OS X”, “macOS”, “for macOS”. These terms are generally added to ported software such as “MAME OS X.app”. Exception: when the software is not a port, and “Mac” is an inseparable part of the name, without which the name would be inherently nonsensical, as in PlayOnMac.app.

And that the project specifically markets itself as 'Razer macOS', which matches user expectations in looking for it:

• https://github.com/1kc/razer-macos

The "macOS" suffix seems as much a part of it's name as anything else; it's not describing a port/etc; which is why I believe the exception (described above) is relevant.

That said; I would also be happy to accept razer-unofficial; and if the search stuff worked properly and matched on the name, then I probably would never have had a problem/thought to bring up renaming (or read so deeply into the specifics of the renaming rules) in the first place; so that would probably also make it a 'non-issue' for me.

---

Thank you for your in-depth analysis of the situation here

@bevanjkay No problem :) I figured I would try and answer my own question first; or at least provide relevant context to help get a better answer.

Regarding the issue in Homebrew/brew that could be somewhat related - Homebrew/brew#16237
Parsing the name text (and desc text, as plain text) may help in this situation. But I would suggest that perhaps consideration could be given to including the name by default in brew search or adding a separate flag, as requiring the use of --desc to search the name is not immediately apparent.

@bevanjkay nods that makes sense. Thanks for the link :) I'll leave musings about the deeper specifics of that for once I've read the linked issue; and will probably add my thoughts there if I have any, as this PR doesn't seem like a good place for them not to get lost.

[bevanjkay]

It may just be that the way those docs are written is a little ambiguous, but it seems to be 2 different cases, merged into one (which is what I was trying to say earlier about it not being a fork (Ref)):

I think the issue here is more to do with the way the docs link back to the information about "forks".

The cask cookbook is a bit more direct;

https://docs.brew.sh/Cask-Cookbook#potentially-misleading-name

If the token for a piece of unofficial software that interacts with a popular service would make it look official and the vendor is not authorised to use the name, a prefix must be added for disambiguation.
In cases where the prefix is ambiguous and would make the app appear official, the -unofficial suffix may be used.

Therefore the vendor prefix is used first, then if it's still ambiguous the -unofficial suffix can be considered.

[0xdevalias]

@bevanjkay For context; I originally started at the cask cookbook, and followed through to that other page in deciding that the name I was suggesting (Ref) seemed correct.

Therefore the vendor prefix is used first

If that is what the below docs are intending to suggest:

a prefix must be added for disambiguation

Then they could definitely do with a refactor to make that clearer. As currently to me, that reads more like:

If the token for a piece of unofficial software that interacts with a popular service would make it look official and the vendor is not authorised to use the name, go read this for rules about how to disambiguate it.

Phrased differently, as currently written, it comes across that the word "prefix" in the docs seems more of an arbitrary choice of word, and that the canonical rules are defined by the page it links to.