Consider moving into Homebrew GitHub organisation

[MikeMcQuaid]

• None of the templates was appropriate for my issue, or I’m not sure.

I think the Homebrew/brew merge of brew cask code has been a massive success. I'd like to propose that you consider moving caskroom/homebrew-cask into Homebrew/homebrew-cask. I think this would help unify the projects and communities a little bit more and generally strengthen both projects.

I think it would be cool to also consider moving the other taps over, too. The only problem is a naming collision with caskroom/homebrew-versions and Homebrew/homebrew-versions but I'd also propose considering the addition of the versioned casks into caskroom/homebrew-cask (this would also be consistent with homebrew/homebrew-core).

Thoughts? Concerns? Feelings?

[wickles]

Regarding collisions, it should be noted that there is still some duplication/overlap between some homebrew formulae and casks (see #15603). In particular: emacs, macvim, wireshark, mono/mono-mdk, djview4/djview, etc

[commitay]

@wickles Most are intentional duplicates. From the issue you linked: #15603 (comment)

mono / mono-mdk are very different in how and what they install, the mono formula would require extensive changes* to replace mono-mdk and we would still need to somehow provide compatibility for Casks that require mono and expect it to reside in /Library/Frameworks.

The purpose of this issue at this stage is to discuss if we should move, please keep comments on topic or it will be locked.

*Edit for clarity: I'm not sure if it is possible to build the complete mono-mdk from source.

[reitermarkus]

I‘m definitely in favour of this. Just not sure what would be the best place to start with. Probably allowing versioned Casks in caskroom/versions, i.e. allowing @ in tokens.

[commitay]

I don't really have an opinion either way with regards to moving.

Personally I would oppose splitting up the taps between different organisations, so I think if we do move, we should move all of the taps.

Moving Casks from versions into the main tap would be something I am against, I find it easier to manage and maintain "versions" when they are separated from the main repo.

One potential issue is the impact the Cask repos will have on the overall Homebrew build queue for Travis CI. Builds are queued per organisation, so our traffic will delay builds in Homebrew/brew and the other Homebrew repos that use Travis.

[MikeMcQuaid]

Personally I would oppose splitting up the taps between different organisations, so I think if we do move, we should move all of the taps.

Moving Casks from versions into the main tap would be something I am against, I find it easier to manage and maintain "versions" when they are separated from the main repo.

Unfortunately these are contradictory desires, hopefully as I explained above (I'll happily elaborate if not, though).

One potential issue is the impact the Cask repos will have on the overall Homebrew build queue for Travis CI. Builds are queued per organisation, so our traffic will delay builds in Homebrew/brew and the other Homebrew repos that use Travis.

Homebrew is fine with this 👍

[vitorgalvao]

I’m still thinking about this, and had been waiting for some other opinions first. This is partly to me not immediately seeing a great benefit either way.

I'll happily elaborate if not, though

Could you, please? Why is there a contradiction?

I agree with @commitay. Having versions in a separate repo is to me a clear win in our case. Many of our versioned casks are more than old versions of casks in the main repo. We have a lot of nightly/canary/… that are encouraged to use an url do block to dynamically get the latest version, while the same is discouraged in the other repos. So they are treated differently and are up to different standards; having them in a separate tap makes sense. Having cask@nightly or cask@beta also doesn’t sound right to me (but I’m confident I could be convinced otherwise).

I also agree that to move it’d make sense to either move everything or nothing. I say this because from all the repos, the one that mostly makes sense to stay in a different organisation is the main one. I feel strongly the main repo is much more than a tap — it‘s a place for discussion of policy and documentation that affects a whole group of taps (the ones that have casks).

Formulae and casks are different things and both projects have slightly different aims. We both want to facilitate the management of software, but HB’s rules are more strict about what they allow. We all understand that due to the nature of what we install (a major difference being that HBC allows non-open-source software) it makes sense for both projects to have different rules.

Occasionally (though less frequently than before) we still get users to whom we have to explain those differences. By merging the main tap into the HB organisation, I think that will become harder to explain again. It’ll be even harder to explain why some official taps are in a different organisation.

[MikeMcQuaid]

Could you, please? Why is there a contradiction?

Homebrew/homebrew-versions already exists so Caskroom/homebrew-versions cannot be moved across (unless it gets renamed to something like Homebrew/homebrew-cask-versions).

It’ll be even harder to explain why some official taps are in a different organisation.

I agree with not doing this.

Occasionally (though less frequently than before) we still get users to whom we have to explain those differences.

I'm not sure the org name would change that if everything else remains the same. Worth noting (I'm sure everyone knows this but some readers may not) that Homebrew/brew contains all the brew cask command code at this point.

[vitorgalvao]

unless it gets renamed to something like Homebrew/homebrew-cask-versions

Couldn’t we change the core to allow taps to have a caskroom- prefix as well as a homebrew- prefix? Internally the former would be an alias to the latter, but it’d fix the conflict.

Did we discuss this idea before (I’m getting déjà vu thinking of it)? Is there a reason why it’s not feasible?

[ilovezfs]

I think there's something to be said for consistency.

brew install gcc
brew install gcc@6
brew cask install java
brew cask install caskroom/versions/java8

is the status quo.

I think it would be much nicer for users to be able to

brew install gcc
brew install gcc@6
brew cask install java
brew cask install java@8

[commitay]

Did we discuss this idea before

There was some discussion about this in the previous intergration issue #14384

[vitorgalvao]

@ilovezfs No idea how many people actually type caskroom/versions/ every time. I think it’d be fairer to call it brew cask install java8. That said, I have no issue with java@8 (or more accurately, caskroom/versions/java@8); I do have issue with java@nightly.

Either way, that still does not take into account my argument:

Many of our versioned casks are more than old versions of casks in the main repo. We have a lot of nightly/canary/… that are encouraged to use an url do block to dynamically get the latest version, while the same is discouraged in the other repos. So they are treated differently and are up to different standards; having them in a separate tap makes sense.

That is to me way more important and more maintainable for our own case.

I’m all for more integration between the two projects, but I also think it’s the wrong approach for HBC to do something just because HB does it. It’s imperative to keep in mind that casks and formulae are not just different in terms of code. The nature of the software we allow is so different that if the rules of one project were applied to the other it’d radically change it.

We never shied away from taking for ourselves what fits from HB, but we need to have the autonomy to decide what is best for our own cases.

[vitorgalvao]

Before the discussion extends further, I’d like to ping @caskroom/maintainers. Feel free to comment or not, but some may want to at least follow the discussion and it’s easier to start sooner.

[ilovezfs]

I do have issue with java@nightly

In terms of current use and implementation @ is only valid for version numbers. So for instance, there's an audit to enforce that the unversioned formula (e.g. gcc) has a corresponding alias in the alias directory.

Josephs-MacBook-Pro:homebrew-core joe$ ls -l Aliases/gcc@7 
lrwxr-xr-x  1 joe  admin  17 Dec  9 08:31 Aliases/gcc@7 -> ../Formula/gcc.rb

That allows a user to

brew install gcc@7

So again there's a confusing inconsistency here. brew cask install java8 works but brew cask install java9 does not (yet), whereas brew install gcc@6 and brew install gcc@7 both work.

[MikeMcQuaid]

I agree with @commitay. Having versions in a separate repo is to me a clear win in our case. Many of our versioned casks are more than old versions of casks in the main repo. We have a lot of nightly/canary/… that are encouraged to use an url do block to dynamically get the latest version, while the same is discouraged in the other repos. So they are treated differently and are up to different standards; having them in a separate tap makes sense. Having cask@nightly or cask@beta also doesn’t sound right to me (but I’m confident I could be convinced otherwise).

I think it would be reasonable to exclude them, rename their repo (homebrew-cask-unversioned?) and have stuff like java@8 (that's currently really widely used and recommended by Homebrew) be part of the main repo.

Couldn’t we change the core to allow taps to have a caskroom- prefix as well as a homebrew- prefix? Internally the former would be an alias to the latter, but it’d fix the conflict.

This is technically possible but it's not a good broad change just to avoid a naming conflict.

We never shied away from taking for ourselves what fits from HB, but we need to have the autonomy to decide what is best for our own cases.

We agree here but I would say since the projects were integrated that when there's deviation it's confusing for users. As a (very) long-term thing I think it would be good if pretty much all Homebrew and Cask commands were more similar than different.

So again there's a confusing inconsistency here. brew cask install java8 works but brew cask install java9 does not (yet), whereas brew install gcc@6 and brew install gcc@7 both work.

I think this is a good point.

[commitay]

Moving the Casks from versions to Homebrew/homebrew-versions was mentioned in the previous integration issue, is that not an option?

[MikeMcQuaid]

Moving the Casks from versions to Homebrew/homebrew-versions was mentioned in the previous integration issue, is that not an option?

It's no longer an option because that repository has been deprecated and archived.

[ilovezfs]

That said, I have no issue with java@8 (or more accurately, caskroom/versions/java@8); I do have issue with java@nightly.

Would it make sense then to move all of the stuff with actual versions into the main repository using @, and rename the caskroom-versions repository to caskroom-unversioned?

That said, it does sound to me like the separate repository isn't actually needed, though, as it should be possible to treat the question of when url do is supposed to be used and when it's not supposed to be used as a matter of documentation, auditing, review, code comments, and pr templating just like anything else.

[vitorgalvao]

Would it make sense then to […] rename the caskroom-versions repository to caskroom-unversioned?

No, because there are also unversioned casks in the main repo (the ones where the developer doesn’t provided a versioned download and updates the package in place).

That said, it does sound to me like the separate repository isn't actually needed, though, as it should be possible to treat the question of when url do is supposed to be used and when it's not supposed to be used as a matter of documentation, auditing, review, code comments, and pr templating just like anything else.

The point wasn’t url do, but this (emphasis added):

they are treated differently and are up to different standards; having them in a separate tap makes sense.

Different standards; different treatment; different tap.

[ilovezfs]

OK so can someone please suggest an acceptable name that doesn't involve changing the brew backend?

[ilovezfs]

e.g. maybe homebrew/homebrew-cask-versions or homebrew/homebrew-cask-alternates?

[claui]

@ilovezfs I second that. Been trying back and forth with my own private(-ish) and public taps; the homebrew-foo/homebrew-cask-foo naming scheme has worked best for me personally.

One of my pet goals is, don’t memorize stuff, and don’t design anything that requires others to memorize stuff.

[ilovezfs]

@claui yeah name-spacing all of the cask taps as homebrew/homebrew-cask(-*) would make sense to me since just having the one tap homebrew/homebrew-cask have the word "cask" in it would be pretty confusing.

[reitermarkus]

@caskroom/maintainers, as part of my Google Summer of Code project, I will take on the task of migrating all Cask Taps into the Homebrew organisation.

Any objections to the homebrew/homebrew-cask naming scheme?

• homebrew/cask
• homebrew/cask-drivers
• homebrew/cask-eid
• homebrew/cask-fonts
• homebrew/cask-versions

[fanquake]

@reitermarkus I get a 404 with your GSOC link

[reitermarkus]

Should be working now.

[commitay]

It errors if I try to access it when I'm already logged in to google, works when I log out.

and by merging some brew cask commands with their brew counterparts

Which commands?

[reitermarkus]

Which commands?

search and cleanup

[reitermarkus]

Actually we can (and I think should) create a new separate team that's just for access to all of the Cask stuff.

I already moved the maintainers/brew/cask team to maintainers/cask.

[commitay]

I already moved the maintainers/brew/cask team to maintainers/cask.

The cask sub-team within maintainers/brew was useful for reviews, is it possible to have both?

[claui]

@reitermarkus Happy to see the projects moving closer together! Having been a Cask maintainer since 2014 (with the odd hiatus), I’ve decided to commit to what the New Maintainer Checklist says.

Looking forward to – finally – become part of the org 😊

[claui]

@reitermarkus Thanks for adding me.

I noticed I’ve been added to the cask team. I’ll do Cask maintenance if the project really needs it but I’m neither very skilled nor efficient at it. Working on the Cask core is what I’ve been good at though. That’s what I used to do (until the 2016 reorg came along) and what I’d like to pick up doing.

What would be a good path to get me moved back to the (Cask) core team?

[reitermarkus]

What would be a good path to get me moved back to the (Cask) core team?

I will add you to the Homebrew/brew team. Also, please let me know your email so I can invite you to the Homebrew Slack.

[reitermarkus]

I will begin moving over the taps later today.

[vitorgalvao]

Questions:

1. After moving the taps, will the old ones be immediately dead (breaking every brew cask install caskroom/cask/… command), or will Github redirect automatically?
2. If Github redirects automatically, how long will the redirect last?
3. If Github does not redirect, doesn’t that mean we’ll need a simultaneous HB release that includes the new URLs?

[reitermarkus]

1. Github will redirect it. You can test this: https://github.com/caskroom/homebrew-tap-migration-test
2. I don't think there is a time limit.

[MikeMcQuaid]

There's no time limit; it'll be redirected as long as there's not a new repository created with the same name.

[vitorgalvao]

Just noticed I only have read permissions on the repos.

On another note, just did a quick update to cask-repair (I was hoping the automatic redirect would make it not immediately necessary, but it seems it did indeed break). I’m really tired so I’ll likely go to sleep soon. If there are users complaining about cask-repair not working, please tell them to update (already bumped the formula — it’s at 0.37.0) and that if the issue persists to submit bug reports to https://github.com/vitorgalvao/tiny-scripts instead (the script already says that, but we still get people opening issues in this repo).

Thank you, talk in a few hours!

[commitay]

I've opened #47609 to discuss moving java8

[reitermarkus]

Just noticed I only have read permissions on the repos.

@vitorgalvao, the @Homebrew/cask team has write access to all Cask repos, so not sure why it's not working for you.

@commitay, I also explicitly added read access for Hombrew/brew, so @Homebrew/cask can be used for reviews.

[MikeMcQuaid]

@vitorgalvao, the @Homebrew/cask team has write access to all Cask repos, so not sure why it's not working for you.

I added them yesterday, they were previously just Read.

[commitay]

I also explicitly added read access for Hombrew/brew, so @Homebrew/cask can be used for reviews.

Thanks!

[joshka]

Congrats on the move :) A long time coming. May I suggest that it would be cool to see a blog post on brew.sh about this to close the loop and cover out any of the things that are changing (e.g. analytics #47720, java8 #47609, etc.)

[MikeMcQuaid]

@joshka Thanks! We'll note it as part of the next major release.

[joshka]

On the versions part of this (and this may be something to cut off into another issue - please suggest we do so if this thread is not the right place for this). A particular use case that I'd like to be able to solve easily came up the other day in conversation. A music producer friend had an old track that he wrote using a specific version of a VST (a synthesizer) which he couldn't find again. It would have been nice to be able to say brew cask install some-synth@1.2.3 as the right solution for this.

[vitorgalvao]

@joshka We’re talking about a change in nomenclature, meaning the rules on what old versions to actually include are not likely to change that much. I’d be surprised if in the case of your friend there were even two people in the exact same situation. Keeping multiple versions of plugins is not something we’ll aim for.

[joshka]

It’s exceedingly common with both music software and development software able to run specific point versions of software for compatability reasons. I’m not suggesting that the policy of the main tap changes, more getting an understanding of how to implement this in my own taps where I want the policy to be different.

[mwean]

Yeah I agree. I've had to switch away from homebrew for many of my development dependencies (e.g. postgresql) because I need precise control of versions.

[MikeMcQuaid]

It’s exceedingly common with both music software and development software able to run specific point versions of software for compatability reasons.

For "compatibility reasons" also read "to increase the change of having your machine owned by widely known, already patched security vulnerabilities (particularly on networked software)".

I’m not suggesting that the policy of the main tap changes, more getting an understanding of how to implement this in my own taps where I want the policy to be different.

The same way you handle it on any formula/cask/tap: copy the file you want at the version you want to your own tap and then maintain it there yourself.

I've had to switch away from homebrew for many of my development dependencies (e.g. postgresql)

This is entirely off-topic to this conversation that's not about Homebrew.

[claui]

getting an understanding of how to implement this in my own taps where I want the policy to be different.

@joshka I recommend to do that as suggested in How to Create and Maintain a Tap. It’s an excellent one-pager, and applies for casks as well as formulas.

[joshka]

@claui I created https://github.com/joshka/homebrew-audio last night as a response to and issue of putting all the VSTs that a manufacturer makes into homebrew-cask would blow out the count of casks in the core repo for little upside. In there there are a few examples of this problem on a v1 to v2 cask as well as many examples where I explicitly included every version of every plugin available from d16 in the git history (I scripted the repo creation, I’m not insane). This means a person who needs 1.0.0 when 1.1.0 is out installs from a github link, while a person requiring the latest v1 uses brew cask install foo, and a v2 user does brew cask install foo2. 3 ways to install depending on the version.

When I’m near a computer I’ll raise a seperate issue to track this instead of continuing in this thread.

Mike,
In the case of software upgrades, another thing that explicitly changes is that software versions may be paid upgrades. Just because a piece of software upgrades doesn’t mean it includes any security content. The two problems are not tied to each other.

[adidalal]

As we're going off on a tangent here, I've moved over discussion to #47950.

Thanks,
Aditya

[MikeMcQuaid]

This happened! Nice work @reitermarkus 👏