Make even more repositories?

[vitorgalvao]

This is something I’ve been thinking about on and off for about a year, and that I believe makes even more sense currently, with the amount/different types of casks and the fact this project is now an organisation. I don’t feel that strongly for or against this idea, and it was initially formulated at a time when this project was a different beast, so I’d like to gather if it warrants doing depending on the support it gets.

We have different taps for different goals but they’re all concerned with alternate or tangent versions of what’s already in the main tap. All except one, that is, fonts. Why not also separate qlplugins, prefpanes, and perhaps even binary-only casks?

There are two more kinds of apps I think would benefit from being separated from the main repo¹ (even more than the above examples): games and drivers.

Now, with me having always been vocal against steering the project in a “discoverability” direction, this might seem weird. However, discoverability is about marginal differences (genres, if you will); what I am talking about is separating entire classes of purpose. While styles/genres of apps can overlap/be hard to define (one of the biggest issues with implementing discoverability features), here we’re talking about well defined categories of applications — apps that have such different intents, there’s no way they could be confused, and could actually benefit from being separated.

---

¹ The ones that made me start to think about this idea, when they were first introduced

[rolandwalker]

We moved fonts to a separate repo because of license concerns. But it ended up being a practical/administrative necessity because that repo is quite large, and because a slightly different set of maintainers process submissions.

The current technical issue with organizing Casks into repos is that Cask names cannot collide, even if they are in separate repos, so separating them buys us little. This is something I hope to start addressing after DSL 1.0, as the new notation in #5365 is intended to move us away from using toplevel classes for Casks. If (instead) we store a series of Cask instances, we could disambiguate them by pathname.

At least on the CLI, that is. When it comes to installation, we face the same limitation, as the Cask name is used for the directory name where the distribution is stored in the caskroom. And once again, these names cannot collide. We might consider changing the caskroom directory layout to lift the limitation, though it would pretty much break all existing installs.

[tapeinosyne]

I will focus on usage, as @rolandwalker outlined the technical implications.

The “categories” you describe are unambiguous, but the criteria to decide what constitutes a category might not be. I suspect that different users would have diverging expectations.

For example, I would find the following categories to be most intuitive:

• main: gui apps, cli apps / binary software, games;
• system “extensions”: quicklook plugins, prefpanes;
• fonts;
• drivers.

If I were to rationalize my preference, I would argue that I am segregating casks by access method and requirements. “Main” includes standalone casks which are meant to be used directly. “Extensions” hosts casks the functionality of which is bound to specific pre-installed software. Fonts are binary artifacts which are used solely through other software. Drivers are install-and-forget affairs with hardware dependencies and catastrophic failure modes.

However, it is easy to spot the fuzzy contours of this logic. Asepsis is an install-and-forget affair; should it be treated as a driver?

Homebrew itself follows a mix of criteria, including “intent”: their main repository is heavily skewed toward packages for software development, while everything else (scientific software, games) is maintained elsewhere.

Principles aside, my concern is that we might end up categorizing to appease our sense of aesthetics and neatness over the benefit for end users. We should only require additional brew taps with good reason.

[tcarlsen]

i agree with @rolandwalker and @ndr-qef that categorising the cask will be a messy affair.

But with that said maybe having a specific repo for games would make sense?

[tapeinosyne]

Reading back my previous message, I realize it was more argumentative than originally intended.

With a sufficiently low number of repositories, we are very much free to introduce new ones for arbitrary reasons. @rolandwalker mentions that simple administrative convenience is a factor in the existance of caskroom/fonts.

On the user-facing side of the matter, my primary concern is that improving search might provide similar benefits without the requirement of taps. @vitorgalvao, perhaps you would like to describe the benefits of separation by “category” in greater detail?

[vitorgalvao]

@ndr-qef As I said, I’ve been thinking about this for quite a while, and the project as changed so much, I’m not sure if it’s still a good idea or I’m clinging to how well I once thought it could work. The key takeaway in my original post is “[t]here are two more kinds of apps I think would benefit from being separated from the main repo: games and drivers. (…) apps that have such different intents, there’s no way they could be confused, and could actually benefit from being separated”.

I’m thinking games and drivers are so different from “regular apps”: they’re the kind of taps someone may care about, even if they don’t care about the main repo (important point, as well). I’m also thinking this would incentivise the inclusion of more games and drivers. At least I do find there is some kind of mental separation, as if they’re out-of-place on the main repo.

[rolandwalker]

The technical issues I raised could be resolved by reorganizing /opt/homebrew-cask/Caskroom/ as /opt/Caskroom/homebrew-cask/, placing each repo under its own subdir, eg /opt/Caskroom/homebrew-versions/.

Actually transitioning the current installed base would require nontrivial effort.

[vitorgalvao]

Reading back my previous message, I realize it was more argumentative than originally intended.

Actually, @ndr-qef, I just re-read the whole issue and thought of your first post as nothing short of convincing and clear. I’m in agreement with you all.

Lets close this.

[radeksimko]

As mentioned on IRC, I think this is a good idea, but also agree with @rolandwalker 's concerns regarding naming clash across taps, so I'd keep this open, so we don't forget, but postpone action steps until DSL 1.0 is out?

[vitorgalvao]

Closing. Will open a new one in a few moments.