Make more repositories?

[vitorgalvao]

This is a bit of a rehash of #5876, and part of it applies mostly the same:

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

It has been two years since that discussion, and the current team is different. No conclusion was arrived at at the time, so I’d like to rehash the conversation with the current team. Coincidentally, I had been thinking about this a lot when @reitermarkus introduced the idea of having all language versions in the same cask, and that fits nicely with this new proposal:

• caskroom/cask: Casks that use app, pkg, binary, suite, artifact, installer, stage_only. The main repo.
• caskroom/versions: For different versions of casks in caskroom/cask. Include no-longer-developed and not-yet-stable versions. Classic, developer edition, early access, canary, beta, alpha, nightly versions all belong here.
• caskroom/fonts: Keep as is.
• caskroom/eid: Keep as is.
• caskroom/games: Self-explanatory.
• caskroom/drivers: Software with the sole goal of making a hardware peripheral recognisable by the system. If a cask is useless to anyone who does not have a particular hardware peripheral, it’s likely a driver.
• caskroom/libraries (addons?): Everything that goes in ~/Library with the exception of fonts (which deserve their own tap for being so many): colorpicker, input_method, internet_plugin, prefpane, qlplugin, screen_saver, audio_unit_plugin, vst_plugin, vst3_plugin.

Editions/alternative versions (community editions, pro editions) would go back to main repo (with the exception of developer editions which are more geared for the same audience as canaries and nightlies). I never felt like users were truly happy with the current arrangement, and have occasionally contested the decision of how we choose the “main” one. Though our rule is clear, it may not be intuitive. “Versions” in the name would make even more sense and be more appropriate. Regional versions (i.e. pokerstars vs pokerstarseu) still belong here.

I think games being in their own tap could be valuable to users. We’d be a more serious repository of games where you don’t need an account to download, and that seems like it could be a good thing. Perhaps if it is popular, more game developers will offer direct-download options, not tied to proprietary stores.

Divers always seemed out of place in the main repo, to me. They typically (always?) have cryptic names and are useless to most users, cluttering the repo. Keeping all that “garbage” in the same repo seems sensible.

I’m also suggesting caskroom/libraries, even though I feel less strongly about that one, because those are a bit all over the place naming-wise and number-wise. Some of those have a single cask and if we ever removed the casks, we might not even notice the zombie stanza. Having them all in the same repo would make it easier for us to organize them and decide on a naming scheme.

If a cask should logically fit in a certain repo but its stanza says it belongs in another, logic should dictate its location (to go for user expectations). Example: electric-sheep installs a screensaver but uses a pkg stanza. It should go in caskroom/libraries all the same.

In the case a cask has (for example) both an app and a prefpane, caskroom/cask takes precedence (the stanzas that exist in greater numbers have more “weight”).

Pinging @caskroom/maintainers, but any user is welcome to chime in.

[mwean]

This sounds good to me. Breaking things up into separate repos also makes things more manageable. You can't even view /Formula in homebrew-core in Github because there are too many 😕

[adidalal]

Yes to the idea, but no in practice.

Anything outside the main repo gets relatively little maintenance, in my opinion. (though I know @victorpopkov at least runs the -upgrade script on -versions at least).

-versions should be pretty clean after the (proposed) language enhancement, anyway.

Out of sight, out of mind, in my opinion.

[vitorgalvao]

@adidalal Though I agree casks in other repos might guess less updated, I think that’s a consequence of them being less popular/useful than being in other repos. The ones that are updated (by contributors) are religiously so.

And think about the division I’m proposing — the casks that would be separated from the main repo are the ones that are less updated already. Games and drivers don’t need and don’t get many updates. Plugins also don’t get much attention: a few are popular (and only sporadically updated as well, since by being so small they are mostly complete already), but most are unchanged.

For this particular division, I don’t think the casks update cycles will be meaningfully affected. On the contrary, if you have a place where all the cryptic driver names are bundled, you may be more successful in finding yours/adding new ones. Same for games.

[reitermarkus]

Yes to the idea, but no in practice.

I have to agree with @adidalal here. With the ongoing multilingual cask PRs I have to say that even switching back and forth between only two repos is exhausting.

[vitorgalvao]

@reitermarkus And this change will allow you to switch less between repos, because different editions go back to the main repo.

All the things that would leave the main repo are the casks that get less updates and have less users because they’re very specific (games, screensavers, drivers, audio plugins, …, are all very specific requests that fit very specific personal needs). Having them separate gives them more visibility.

Seitching between repos is exhausting if you’re moving files around, sure, but users do not have to do that.

Lets not forget the huge amount of official repos HB has for even the tinyiest of separations, and it seems to work well for them.

[vitorgalvao]

@adidalal @reitermarkus Are you still 👎 on the idea, or did my replies make you 👍?

Would also like some input from @jawshooah @victorpopkov @Amorymeltzer @fanquake. Right now we’re three 👍 (me, @mwean, and @alebcay on the top post) for two 👎 (@adidalal @reitermarkus unless any of you changed your mind). I wouldn’t like to implement this (or not) with some maintainers begrudgingly accepting it. Ideally, there could be an argument to sway everyone to one camp.

Also, I’ll point out again any user is welcome to chime in.

[reitermarkus]

or did my replies make you 👍?

Still not completely 👍, but I could live with at least games and drivers in separate repos (and I won't complain if there will be more).

[adidalal]

drivers should be reasonable if we're really pushing to separate those out but really not particularly keen on adding more repos. That's even more for users to tap/us to manage/etc. Homebrew has a bigger team and more contributors, which is why they can manage all the sub-repos (and also, per-repo maintainers).

[victorpopkov]

I'm fully 👍 with this idea. Even though other repositories will be less updated I don't think this will become a huge problem. Sure thing, switching between the repositories is exhausting, but creating separate repositories for games, drivers and libraries, in my opinion, is a good thing to do.

[Amorymeltzer]

Generally all 👍 for this, especially the libraries/addons (I like libraries, fwiw) change. My initial thought was no, it just over-complicates things and creates a more diffuse process, but I think, given the nature of the project, we can expect our users to take an interest in finding what they need and would not be too put-out by having a few extra repos. More to the point, it would allow people to ignore things they don't care about — I'm thinking about finding/being notified about available updates, for example — and would allow maintainers easier batch edits. If you're editing files, it's not a bad idea to balkanize things a bit; switching repos is probably the easiest part of managing git. 😉

My only exception is to games, which I'm not sold on. I see the argument for encouraging additions, but with the other categories my impression is people think about them differently. Drivers and libraries and fonts are different file types, and nobody would call them an "app" or "application." Games, on the other hand, I think any reasonable person would call an "app" and would expect to find, say, the minecraft app in the main repo.

[adidalal]

Will this kill discoverability - should probably be able to search/auto-tap these other repos, otherwise they'll remain obscure?

[vitorgalvao]

should probably be able to search/auto-tap these other repos

I’d have no issue with cask, drivers, libraries being auto-tapped. Alternatively, I’d say we expand #16732 to include those repos. HB seems to do a good job of searching their other non-tapped repos, no reason we shouldn’t be doing that anyway.

And what about

Editions/alternative versions (community editions, pro editions) would go back to main repo (with the exception of developer editions which are more geared for the same audience as canaries and nightlies). I never felt like users were truly happy with the current arrangement, and have occasionally contested the decision of how we choose the “main” one. Though our rule is clear, it may not be intuitive. “Versions” in the name would make even more sense and be more appropriate. Regional versions (i.e. pokerstars vs pokerstarseu) still belong here.

Any opinions there?

[reitermarkus]

And what about

I would move everything back to the main repo, except developer versions and specific versions, e.g. sublime-text2.

Also, just leaving this here: Homebrew/brew#1075 (comment)

[vitorgalvao]

Also, just leaving this here: Homebrew/brew#1075 (comment)

That is very important context. With that in mind, my view:

(A bit of a sidenote, first:) We no longer have a boneyard (I think we called it something else I don’t recall) because in our case it was absolutely useless. No one cared for it and we never recovered anything from it.

I think in our case the linked comment actually reinforces the case for the other taps (except perhaps games), because those casks are already mostly abandoned. They’re so neglected, we haven’t even come up with the rules for naming them (or cared much for it). Like I said in the top post:

Divers always seemed out of place in the main repo, to me. They typically (always?) have cryptic names and are useless to most users, cluttering the repo. Keeping all that “garbage” in the same repo seems sensible.

I’m also suggesting caskroom/libraries, even though I feel less strongly about that one, because those are a bit all over the place naming-wise and number-wise. Some of those have a single cask and if we ever removed the casks, we might not even notice the zombie stanza. Having them all in the same repo would make it easier for us to organize them and decide on a naming scheme.

I’m hoping that by moving them to other repos, we actually get a sense of how (little) updated those are and can use that information to better serve those types of casks. Also keep in mind our fonts repo is not exactly a failure, so we do have a precedent.

[BenjaminHCCarr]

I think this is a great idea.
That said I really like the idea of auto-tap or at least auto-search

tyr:~ benc$ brew tap | grep -c homebrew
19

Things like -fuse -science -python -x11

I believe that breaking things out would increase discoverability, as unless you clone the repo to $LOCAL the formulas are far too long to list.

Since this an update in core I would advocate for auto-search for all; and posit the idea of a menu on initial tap [Y/n/a] option for all nested repos (if you even need to tap cask at all anymore, it's been so long).

[wamatt]

Splitting up the namespace / repo seems like a nice idea. That is, assuming this change goes hand in hand, with an equal or enhanced level of discoverability.

[joshka]

Another option would be to use folders under the Casks directory. This has the benefits of organizing things nicely (and allowing github directory listings to work), but none of the problems of added maintenance / update cycle of more repositories. The only thing you lose is the ability to have permissions / specific maintainers per repository.

It would also lend itself well to being extended to allow for -versions to come into the main and solve some of the editions arguments (i.e. Ableton Standard / Suite are editions of the same product, but neither is necessarily more important than the other). Say something like:

Casks/main/
- a-simple-cask-that-has-no-versions.rb
Casks/main/1password/
- beta.rb
- latest.rb
Casks/main/ableton-live/
- beta.rb
- lite.rb
- standard.rb
- suite.rb
- trial.rb
Casks/main/microsoft-office/
- 2011.rb
- 2016-home.rb
- 2016-business.rb
Casks/games/
-bioshock.rb
...

One major benefit of this arrangement is the ease of updating all versions / editions of the software correctly when a version bump occurs. It's one or more commits in a single PR rather than several across multiple repos. This may not sound like it's relevant until you take a look at the current Ableton versions (trial = 9.2.1, standard = 9.5, suite = 9.7, lite = does not exist). All of these should be at 9.7.1

[miccal]

I defiantly support the idea of caskroom/drivers and caskroom/libraries, especially drivers; to echo @vitorgalvao:

Divers always seemed out of place in the main repo, to me. They typically (always?) have cryptic names and are useless to most users, cluttering the repo. Keeping all that “garbage” in the same repo seems sensible.

This is absolutely the case - updating these things (like their homepage) is always a pain.

[vitorgalvao]

It seems that we’re all in agreement in most of this, and the most controversial parts can be fixed by either improving search to search all repos by default (even if untapped) or just tapping them all at install time.

Let’s take it in steps and start with the most uncontroversial stuff of the bunch, and we can reevaluate from there:

• Move editions back to the main repo (adding_a_cask: editions back to main repo and nomenclature additions #29356 and [hold] readme: editions back to main repo homebrew-cask-versions#3188).
• Move drivers to their own repo (adding_a_cask: editions back to main repo and nomenclature additions #29356 and https://github.com/caskroom/homebrew-drivers/).

[adidalal]

Version consolidation sounds good and no opinion really on the drivers
:+1

[miccal]

• Move editions back to the main repo

Homebrew/homebrew-cask-versions#3219

[miccal]

• Move editions back to the main repo
• Move drivers to their own repo

Except for the (likely) possibility I have missed some, these are now complete.

I think adding one more repository, namely caskroom/libraries, is all we need for now, so we would have:

• caskroom/cask: Casks that use app, pkg, binary, suite, artifact, installer, stage_only. The main repo.
• caskroom/versions: For different versions of casks in caskroom/cask. Include no-longer-developed and not-yet-stable versions. Classic, developer edition, early access, canary, beta, alpha, nightly versions all belong here.
• caskroom/fonts: Keep as is.
• caskroom/eid: Keep as is.
• caskroom/drivers: Software with the sole goal of making a hardware peripheral recognisable by the system. If a cask is useless to anyone who does not have a particular hardware peripheral, it’s likely a driver.
• caskroom/libraries: Everything that goes in ~/Library with the exception of fonts (which deserve their own tap for being so many): colorpicker, input_method, internet_plugin, prefpane, qlplugin, screen_saver, audio_unit_plugin, vst_plugin, vst3_plugin.

I think that is a good layout.

[reitermarkus]

caskroom/libraries

I'd call it caskroom/plugins, since the majority of the corresponding stanzas are suffixed with _plugin, and none of them really is a library.

[vitorgalvao]

I'd call it caskroom/plugins, since the majority of the corresponding stanzas are suffixed with _plugin, and none of them really is a library.

No quarrel with that. Makes sense.

[commitay]

If caskroom/plugins is still going ahead I'm willing to make a list for maintainers to approve and do the migration PRs.

[vitorgalvao]

@commitay In some way, if we have the list we might make a more informed decision about going ahead with it or not.

[commitay]

@vitorgalvao Would you like me to post a list here or open a new issue?

[vitorgalvao]

Here works fine.

[commitay]

This list has casks that have _plugin type stanza in them or mention a .plugin file.

I've probably missed many that should be here but don't have plugin type information.

prefpane

• 8tracksradiohelper.rb
• apptrap.rb
• auftakt.rb
• automatic.rb
• backblaze.rb
• basictex.rb
• bassjump.rb
• choosy.rb
• cleanapp.rb
• clusters.rb
• cocoaspell.rb
• cursorcerer.rb
• deploystudio.rb
• earthdeskprefpane.rb
• functionflip.rb
• glimmerblocker.rb
• gpgtools.rb
• growl-fork.rb
• hazel.rb
• hosts.rb
• hyperdock.rb
• jitouch.rb
• launchrocket.rb
• liteswitch-x.rb
• mactex.rb
• magic-launch.rb
• medialink.rb
• menumeters.rb
• mercurymover.rb
• mongodbpreferencepane.rb
• mouse-locator.rb
• music-manager.rb
• notifyr.rb
• orfo-plus.rb
• orfo.rb
• osxfuse.rb
• postgrespreferencepane.rb
• printopia.rb
• rcdefaultapp.rb
• rcenvironment.rb
• shades.rb
• simplifyextras.rb
• smart-scroll.rb
• smoothmouse.rb
• steermouse.rb
• switchresx.rb
• tvshows.rb
• vox-preferences-pane.rb
• web-sharing.rb
• witch.rb
• yujitach-menumeters.rb

qlplugin

• betterzipql.rb
• brushviewql.rb
• emin-webpquicklook.rb
• epubquicklook.rb
• figtree.rb
• hetimazipql.rb
• inloop-qlplayground.rb
• invisorql.rb
• jupyter-notebook-ql.rb
• provisioning.rb
• provisionql.rb
• qlcolorcode.rb
• qlgradle.rb
• qlmarkdown.rb
• qlmobi.rb
• qlnetcdf.rb
• qlplayground.rb
• qlprettypatch.rb
• qlrest.rb
• qlstephen.rb
• qlswift.rb
• quickgeojson.rb
• quickjson.rb
• quicklook-csv.rb
• quicklook-json.rb
• quicklook-pfm.rb
• quicklookapk.rb
• quicklookase.rb
• quicknfo.rb
• quickpvr.rb
• receiptquicklook.rb
• scriptql.rb
• stringsfile.rb
• thong.rb
• ttscoff-mmd-quicklook.rb
• voxql.rb
• webpquicklook.rb

colorpicker

• colorpicker-antetype.rb
• colorpicker-developer.rb
• colorpicker-hex.rb
• colorpicker-propicker.rb
• colorpicker-rcwebcolorpicker.rb
• colorpicker-skalacolor.rb
• colorpicker.rb

input_method

• baiduinput.rb
• google-japanese-ime.rb
• mcbopomofo.rb
• openvanilla.rb
• sogouinput.rb
• squirrel.rb

internet_plugin

• aliedit.rb
• aliwangwang.rb
• blue-jeans-browser-plugin.rb
• box-edit.rb
• flash-npapi.rb
• flash-player-debugger-npapi.rb
• flash-player-debugger-ppapi.rb
• flash-ppapi.rb
• folx.rb
• ip-inside-agent-for-citibank.rb
• java.rb
• silverlight.rb
• skype-for-business.rb
• unity-web-player.rb
• upeditor.rb
• vlc-webplugin.rb
• zoomus.rb

screen_saver

• aerial.rb
• alib1.rb
• chunkulus.rb
• fliqlo.rb
• google-featured-photos.rb
• google-trends.rb
• heart.rb
• ios-saver.rb
• minimalclock.rb
• padbury-clock.rb
• polar-clock.rb
• pongsaver.rb
• save-hollywood.rb
• screensleeves.rb
• screenstagram.rb
• speeds-at-ver.rb
• xscreensaver.rb

audio_unit_plugin / vst_plugin / vst3_plugin

most of these overlap so they are all listed under one heading

• beyerdynamicvs.rb
• deegain-au.rb
• deegain-vst.rb
• deepanpot-au.rb
• deepanpot-vst.rb
• deespeaker-au.rb
• deespeaker-vst.rb
• mobius.rb
• multiply.rb
• proximity.rb
• studiolinkcomponent.rb
• synth1-au.rb
• synth1-vst.rb
• voxengo-span-au.rb
• voxengo-span-vst.rb

dictionary

• dictcc-en-de-dictionary-plugin.rb
• dictunifier.rb
• emojipedia.rb
• eudic.rb
• terminology.rb

service

• emojify.rb
• korean-spelling-checker.rb
• markdown-service-tools.rb
• symboliclinker.rb
• voikkospellservice.rb

casks for file systems

• mounty.rb
• ntfsmounter.rb
• paragon-extfs.rb
• paragon-ntfs.rb
• paragon-vmdk-mounter.rb
• tuxera-ntfs.rb

[alebcay]

Should baiduinput count as an input_method even though it doesn't use the input_method in the actual cask?

[commitay]

• I've added baiduinput and others that have inputmethod uninstalls.

• I'm not really sure how strict I should be with adding casks as moving some but not others of the same type e.g. flash is going to be confusing.

• I've added another 20 or so casks.

[reitermarkus]

I wouldn't expect to find hazel in the plugins repo, since it is actually a .prefpane which includes an .app. Actually, many of the prefpanes feel more like an application to me than a plugin.

[vitorgalvao]

I wouldn't expect to find hazel in the plugins repo, since it is actually a .prefpane which includes an .app. Actually, many of the prefpanes feel more like an application to me than a plugin.

Agreed.

Though the list has errors. None of the flash casks belong in internet_plugin as they’re all pkg, but that only adds to the confusion.

In light of that, I’m now more in favour of not creating that extra repo, meaning we can close this issue if everyone else agrees.

[vitorgalvao]

Alright, just checked a few more on the lists and they definitely have too many false positives. backblaze and glimmerblocker are two blatant ones, for example.

[commitay]

• The list is a WIP, I wanted to find everything that potentially should be in caskroom/plugins before I started removing false positives.

As it seems to be leaning towards 👎 for caskroom/plugins I will leave the list as it is without sorting the false positives, unless the maintainers would like me to continue.

[commitay]

@vitorgalvao While I was going through the casks for plugins I found 37 (so far, I'm still looking) that appear to have hardware dependencies (based on the cask and visiting the homepage) which could be migrated to caskroom/drivers. This doesn't include android / arduino / etc casks that are SDK type programs.

I'll spend some time this week sorting and confirming what I have found before posting it for review but should I put it here or make a new issue?

[vitorgalvao]

@commitay As is more convenient to you.

[commitay]

In light of that, I’m now more in favour of not creating that extra repo, meaning we can close this issue if everyone else agrees.

@vitorgalvao Okay to close this?

[vitorgalvao]

@vitorgalvao Okay to close this?

Fine with me. Thank you for the work on this, everyone.