Integrate Homebrew and Homebrew Cask more closely

[MikeMcQuaid]

Hi, I'm @MikeMcQuaid one of the Homebrew maintainers. I love Homebrew Cask and I'd love to see our projects work more closely together.

A few ideas I had:

• integrate Homebrew Cask so it's installed by Homebrew by default
• move Homebrew Cask/Caskroom repositories into the Homebrew organisation

Feel free to decline either of these. Also, feel free to suggest other things that Homebrew could do to make your life easier.

Thanks for all your great work!

[vitorgalvao]

Hello, Mike, great to have you here, as always. As you may or not already know, I took on the role of lead maintainer a while back, and when I did, I was told you had briefly expressed interest in this previously. The reason I mention this will become apparent in a moment, but before continuing, I’ll bring into the discussion our regular maintainers, in no particular order: @jawshooah @victorpopkov @alebcay @fanquake.

Now, on to discussing this. This will be a huge post, and I’ll bring up some things I have been thinking for a long while about the future of homebrew-cask but haven’t discussed yet. Might as well do it now, since those pertain to a possible project merge.

First, incompatibilities between the projects. One of the things I remember reading on hombrew formulas is that you frown upon (might no longer be the case) a developer submitting a formula for their own app. We don’t, and I believe both of us are correct. I believe your decision is the right one for formulas, and that ours is the right one for casks. They are different types of applications, and should be treated differently. You also require projects to be open-source (am I recalling that correctly?) and that they are correctly tagged and versioned. We don’t, and once again I believe we’re both right. Not only because a good chunk of our apps are commercial (such is the nature of user-facing GUI apps), but because many of them simply do not offer a URL that is versioned (though I do have a possible solution in mind for that, that should at another time).

I mention all that now because you might find those differences unacceptable (which is fine), and if you do there might be no point in continuing to read this monstrosity of a post, as those aren’t really negotiable, since we need them for our users. In the end, we are different projects with different needs, and even though I’m absolutely fine with a bump in transition, regular usage should not be affected (i.e. they shouldn’t lose possibilities).

On to the projects themselves. What I deeply believe we do wrong, and should fix:

• Like homebrew, we link the executables what we download (as opposed to moving or copying).
• Unlike homebrew, instead of having a system that describes step-by-step in order how to install something, we have files that describe the package throughly in which stanza order isn’t really important.

As for the first one, we have an agreement it needs changing and for our projects to merge, this needs to be a possibility.

As for the latter, that is the one I haven’t discussed yet but have been thinking about. As with the previously linked issue (#13201), this decision (of the way it currently works) was made based on an assumption that turned itself to be less and less true the more apps were submitted. Again, linking to one of my favourite posts ever in the history of homebred-cask, being smart doesn’t work.

The reason the system works as it does now is based on the assumption that app bundles are all the same. Unlike homebrew where most install operations can be considered custom to an extent (like running make with certain flags, depending on user choice and the packages themselves), the reverse is true with apps: just download, unpack, link (soon to be “move”). That might very well be true for most packages, but for the ones it is not, oh what great hoops we jump through. Since our operations aren’t executed in the order they are written, workarounds like the *flight stanzas had to be introduced, and what a mess that sometimes turns out to be in practice. Instead of just saying in order what we want to happen, we have to define special rules that will be executed at certain times. This all gets back to #13201 and its simple idea: there are too many edge-cases, more than anyone could predict before actually starting to try to make sense of all the user-facing apps that exist for a particular OS, which is where the quote from The Cathedral and the Bazaar comes in again: “you often don't really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once”.

Now, some clarifications. It’s not like homebrew does everything in order. Things like url and homepage (which we share) do not necessarily need to be part of the install process, no need to have to say every time “download this url, now check against this checksum”, and homepage wouldn’t even make sense in such a system. However, I do think that having a more descriptive installation process could do wonders for us. How far we need to go with this, I still do not know, but again, like #13201 (yes, the ideas for these two are very closely connected), this could alleviate some other burdens like how we create shim scripts, the aforementioned *flight stanzas, and even the old #142, which homebrew can already do to an extent (and which would let us get rid of so many dirty parts of caskroom/versions).

On to technical and organisational problems. The first one is, like I said before, this isn’t something I have discussed before for various reasons, so I don’t have opinions from the rest of the team, yet. What I described is the first phase of my thought process for this possible change. It would, however, scale casks back, to some degree, to the role of formulas. That is a big deal, and likely a huge positive. Why? Because suddenly there’s a smaller barrier to contribute to the other project if you already contribute to one of them, and it would make homebrew-cask be able to advance faster.

I’ll have to explain what I mean by that. Stagnation was recently a real issue for this project. You couldn’t tell from the outside because so many casks were being merged, but core features were essentially frozen. In my view, and I speak solely on my behalf here, this was due to saying “yes” to too many things, many of them I opposed for exactly this reason. This has left us with a bunch of half-baked features, and we currently still lack the people to handle it all. Truth is, we need more ruby developers to work on the core, and getting them is part of my goal. If we share more code with homebrew itself, less work we’d have there.

Speaking of that, you may be aware we at some point in the past separated from homebrew. This in the sense that we copied all the relevant code over and don’t directly depend on it. This was necessary since updates to homebrew broke homebrew-cask for everyone one too many times, and separating was the right move to keep everything working. However, it also meant we don’t get homebrew updates “for free”, and since we now have too few people working on the core, this becomes more of an issue, particularly since the migration still left some things abandoned. Again, scaling casks back to a role more akin to formulas might help us get homebrew’s code again and get the benefit of not having everything break when an update happens.

As mentioned previously, this is just the initial though of a growing idea so I don’t have all the details though out (so I haven’t even checked if everything would be possible or homebrew’s code to support this), but I was envisioning something in the real of, like you have prefix.install_metafiles, bin.install, and others, our pkg, app, bin (might benefit from a different name) would be ported to homebrew to do what we do. Initially I was thinking of these as specific to us, but if we follow your idea of installing homebrew-cask by default with homebrew, then might as well just make it an integral part of the system. That is, naturally, very open to debate, as is everything else.

Finally, what would happen to homebrew-cask’s team? Would we be completely autonomous under the homebrew organisation to make our own decisions regarding casks? I see this as huge since we have a bunch of experience dealing with casks and I trust the rest of the team and our ability to make the best decisions together, so it’s important to me to make sure we still have the final say in matters regarding the cask part of homebrew.

Thank you for reaching out, Mike, and thank you for all your (and the rest of homebrew’s team) work. I’m eager to know your opinions regarding this points, as well as the opinions of the other homebrew-cask maintainers.

[MikeMcQuaid]

In the end, we are different projects with different needs, and even though I’m absolutely fine with a bump in transition, regular usage should not be affected (i.e. they shouldn’t lose possibilities).

I completely agree. To be clear: I think Homebrew Cask is run extremely well and I'd want you to continue to run it however you see fit. Homebrew's formula requirements are and would remain irrelevant to Cask.

Initially I was thinking of these as specific to us, but if we follow your idea of installing homebrew-cask by default with homebrew, then might as well just make it an integral part of the system. That is, naturally, very open to debate, as is everything else.

Yup. I agree. I could see Homebrew Cask having a CaskFormula class (or just a block, like the current way Casks are implemented) which means you don't ever need to write an install method (or, indeed, test or similar). You can use all Homebrew's internal APIs but without needing to implement formulae as we do. Essentially: all the code to actually install/interact with casks could live in Homebrew and the casks themselves could live in a tap.

Finally, what would happen to homebrew-cask’s team? Would we be completely autonomous under the homebrew organisation to make our own decisions regarding casks? I see this as huge since we have a bunch of experience dealing with casks and I trust the rest of the team and our ability to make the best decisions together, so it’s important to me to make sure we still have the final say in matters regarding the cask part of homebrew.

You would be completely autonomous, yes. You're doing a great job and I don't want to mess with that. If the Homebrew and Cask core code merged obviously there'd be debate about the parts of the core code that overlap but by the sound of things that wouldn't be an objection. I'd propose we make a homebrew-cask tap which your team has complete admin rights for.

[alebcay]

Stagnation was recently a real issue for this project. You couldn’t tell from the outside because so many casks were being merged, but core features were essentially frozen.

I've noticed this in the past few months. We've done a good job hiding it by slathering the pull requests page with a bunch of colorful tags, but the infrequent release cuts show that not much is being added to the core.

I do think that having a more descriptive installation process could do wonders for us. How far we need to go with this, I still do not know, but again, like #13201 (yes, the ideas for these two are very closely connected), this could alleviate some other burdens like how we create shim scripts, the aforementioned *flight stanzas, and even the old #142, which homebrew can already do to an extent (and which would let us get rid of so many dirty parts of caskroom/versions).

Definitely +1 for this. There are some cases in which a procedural Cask DSL would have been very helpful. For example, I once proposed that we consider using AppleScript for getting through GUI installers/uninstallers that would be otherwise impossible, but it would be rather ugly to implement in the Cask DSL as it currently stands. If we choose to transition to a more procedural DSL, the fact that most Casks already have a fairly standardized order of stanzas would make the transition less stressful.

If we're switching to a more procedural DSL, I would also suggest that we consider adding some sort of constructs for building apps from source code. While I think we should still prefer installing binaries over building, simply because apps are often more finicky to build than CLI software/libraries, etc., it would still be helpful for some apps that don't provide binary releases. If we have any sort of unification between the Homebrew/Homebrew Cask codebases, all that would have to be implemented to allow building apps would be some mechanism for running xcodebuild. Some other apps are even nice enough to provide a Makefile or other stuff, so that we don't even have to directly invoke xcodebuild. Thus, if some Homebrew methods are made available to Homebrew Cask, the additional effort to allow building apps would be minimal.

Another thing I like about Homebrew that I wish we had in Homebrew Cask is the special download strategies that Homebrew has. For example, the ability to specify mirrors, which have saved me when installing Formulae on several occasions, was quite nice. We've discussed the possibility of localization stanzas for housing apps that have separate versions for different locales (e.g. Firefox, OpenOffice), but that never came to fruition, and thus, there is a pile of Casks sitting in caskroom-versions that needs to be updated en masse every time Mozilla pushes an update through. If we decide to allow some sort of mechanism for building apps as stated above, it would also be handy to have the git, svn, etc. support that Homebrew has.

Regarding the question of actually being integrated into the Homebrew organization, I think it would encourage code sharing, and some work on the core right now is definitely welcome. It seems that little would change for us in terms of actually managing the project and managing actual Cask files, apart from refactoring core:

You would be completely autonomous, yes. You're doing a great job and I don't want to mess with that. If the Homebrew and Cask core code merged obviously there'd be debate about the parts of the core code that overlap but by the sound of things that wouldn't be an objection. I'd propose we make a homebrew-cask tap which your team has complete admin rights for.

so I personally feel no qualms about making such a transition. Dealing with core overlap could get a little ugly, but I think it would be worth it in the long run.

The issue of whether or not to include Homebrew Cask by default seems like a trivial decision to me, because the people that need to use Cask can find it pretty easily anyways, and the percentage of people that wish they had something like Homebrew Cask but don't know about it (and are incapable of using Google to find it) is pretty slim, especially after LifeHacker did a write-up on us.

[MikeMcQuaid]

Definitely +1 for this. There are some cases in which a procedural Cask DSL would have been very helpful. For example, I once proposed that we consider using AppleScript for getting through GUI installers/uninstallers that would be otherwise impossible, but it would be rather ugly to implement in the Cask DSL as it currently stands. If we choose to transition to a more procedural DSL, the fact that most Casks already have a fairly standardized order of stanzas would make the transition less stressful.

I think that if you become part of Homebrew DSL changes will require a bit more cooperation from both sides. I'd also advise against (as @vitorgalvao seems to suggest above) adding more DSL complexity for niche cases but that'd be up to the Cask team.

If we're switching to a more procedural DSL, I would also suggest that we consider adding some sort of constructs for building apps from source code. While I think we should still prefer installing binaries over building, simply because apps are often more finicky to build than CLI software/libraries, etc., it would still be helpful for some apps that don't provide binary releases. If we have any sort of unification between the Homebrew/Homebrew Cask codebases, all that would have to be implemented to allow building apps would be some mechanism for running xcodebuild. Some other apps are even nice enough to provide a Makefile or other stuff, so that we don't even have to directly invoke xcodebuild. Thus, if some Homebrew methods are made available to Homebrew Cask, the additional effort to allow building apps would be minimal.

I think this is something I'd feel relatively strongly about: I think if Homebrew and Homebrew Cask move together then Cask should take over homebrew-binary and Homebrew should stick to building application bundles. I think it's a confusing distinction if both Homebrew and Homebrew Cask are building app bundles and shipping them. If Cask does ship app bundles they should be prebuilt like e.g. Homebrew bottles are and installed for end-users in the same way existing Casks are.

The issue of whether or not to include Homebrew Cask by default seems like a trivial decision to me, because the people that need to use Cask can find it pretty easily anyways, and the percentage of people that wish they had something like Homebrew Cask but don't know about it (and are incapable of using Google to find it) is pretty slim, especially after LifeHacker did a write-up on us.

I wouldn't underestimate how this would improve your discoverability. Most random Homebrew users I've met and I've told about Homebrew Cask hadn't heard of it. I think that's a shame given how awesome a tool it is.

[vitorgalvao]

Thank you for clarifying all my questions. The more I think about it, the more I like the prospect. This would mean in a big part rewriting a lot of homebrew-cask from the ground up, which I personally see as a big win. We could implement a lot of things better if coupled to homebrew.

I’d still like to hear from @fanquake, @victorpopkov, and @jawshooah as well.

[MikeMcQuaid]

Thank you for clarifying all my questions. The more I think about it, the more I like the prospect. This would mean in a big part rewriting a lot of homebrew-cask from the ground up, which I personally see as a big win. We could implement a lot of things better if coupled to homebrew.

I'd strongly suggest that you don't make that a requirement but instead we work on integrating the existing code into core first and then try and use more of Homebrew's stuff over time.

[vitorgalvao]

Yes, don’t worry, I agree we should start with what we have and then chop back what we don’t need.

[fanquake]

Sorry I haven't been keeping quite up to date with this, and haven't had a chance to read through all the comments/discussion. In general I think it's probably a good idea, as long as we maintain our autonomy, and that looks to be the case. Although, what happens as we move more & more of the cask code into Homebrew core?

If we did merge, would we have the opportunity to use, or expand and use, some of the homebrew automated testing infrastructure? I've been looking into automated updates for our versions repo, (which will also need to be renamed in a merge), and a brew bot type setup would work well for automating out some of the nightly/hourly cask updates. Although as cask becomes more complex, ideally we'll cut a lot of the casks out of versions.

[MikeMcQuaid]

In general I think it's probably a good idea, as long as we maintain our autonomy, and that looks to be the case.

Definitely.

Although, what happens as we move more & more of the cask code into Homebrew core?

There may be some loss of autonomy on the core code specifically in that case. Obviously if a Cask maintainer wants to make a core change that will cause other Homebrew issues: that won't be OK

If we did merge, would we have the opportunity to use, or expand and use, some of the homebrew automated testing infrastructure?

Yes. That said: we're currently trying to move more of it to Travis CI due to the pain of maintaining it. That's not to say you won't be able to use it but if you use it you'll need to help maintain it 😀

[RandomDSdevel]

If this happens, then I'd like to see more Homebrew commands than just brew update automatically take care of their Homebrew Cask equivalents. For example:

• brew outdated could show outdated Casks.
• brew upgrade could also run brew cask upgrade( if and when that comes online, that is…)
• brew cleanup could run brew cask cleanup.
• brew doctor could run brew cask doctor.

Some work might need to be done on the differences between the two systems' commands' outputs in order to make that function, though, particularly in the latter two cases.

[MikeMcQuaid]

@RandomDSdevel Agreed.

[RandomDSdevel]

@MikeMcQuaid: Another thing that could be fixed is that the results of updating caskroom/homebrew-cask and caskroom/homebrew-versions don't show up with the results of updating the rest of your taps when you run brew update, and this could also be an issue for other caskroom-based (and possibly even all homebrew–repository-external) formulas/Casks/etc..

[MikeMcQuaid]

@RandomDSdevel 👍

[RandomDSdevel]

@MikeMcQuaid: You're welcome!

[vitorgalvao]

@MikeMcQuaid Another question: how would we deal with our other repos? I’m concerned specifically with cases like caskroom/versions. From the way homebrew handles taps, that repo is called homebrew-versions, but another repo with that name already exists in homebrew. So we’d need to rename those, or is there a better way of handling it?

[RandomDSdevel]

@vitorgalvao: Didn't you say something in regard to Issue #142 earlier on in this very same thread? Oh, wait; here it is:

…However, I do think that having a more descriptive installation process could do wonders for us. How far we need to go with this, I still do not know, but again, like #13201 (yes, the ideas for these two are very closely connected), this could alleviate some other burdens like how we create shim scripts, the aforementioned *flight stanzas, and even the old #142, which homebrew can already do to an extent (and which would let us get rid of so many dirty parts of caskroom/versions).

…

But what did you mean by 'homebrew can already do this to an extent?'

[vitorgalvao]

Why is it always the people who don’t actually contribute that keep arguing senslessly about the direction of the project like they know all its intricacies? It’s at this point we know why some developers snap and just say “fork it and build it yourself”. Though I personally won’t do it because I don’t think it is necessarily a fair answer, I unfortunately understand the sentiment.

Your comment is clearly a response to the other issue, so I’ll ask that you stop spamming other issues with it. Your sarcasm is also not appreciated. It is absolutely fine to disagree and ask for clarification. It is not OK to hijack other issues and keep screaming for the feature you want when you have been told in no unclear terms “absolutely not, but perhaps in the future, though unlikely” and have been told exactly what “in the future” actually means and why it can only be considered again at such time.

This issue/thread is about the merging of projects, not features. It is already big enough to read, and we’re still waiting on the replies of other maintainers. If you can’t take a “no” to your idea, when the reasoning has been explained multiple times, then I kindly ask you to leave.

[RandomDSdevel]

@vitorgalvao:

Why is it always the people who don’t actually contribute that keep arguing senslessly about the direction of the project like they know all its intricacies? …

Because we want to get involved as end-users (and, hopefully, start contributing eventually,) obviously!

…It’s at this point we know why some developers snap and just say “fork it and build it yourself”. Though I personally won’t do it because I don’t think it is necessarily a fair answer, I unfortunately understand the sentiment.

…

I'm sorry to have made you feel that way. I didn't mean to, and I promise to try and be more careful in the future.

…

Your comment is clearly a response to the other issue, …

Which other issue, #142: 'Allow for more flexibility with multiple versions of the same app' or #14833: 'Application Auto-Update Interfacing and Automation, the latter of which is, even though it may be what might have gotten you mad at me in the first place, irrelevant to this discussion? I'm happy to let the latter issue sit and gather dust, and I only mentioned the former issue because you referenced it in the first place and I was wondering exactly why you did; I apologize for not being more clear about this.

…so I’ll ask that you stop spamming other issues with it. …

I don't intend to mention it again unless somebody else believes that it has to do with this discussion first.

Your sarcasm is also not appreciated.

Again, I did not mean to come off as sounding sarcastic.

…It is absolutely fine to disagree and ask for clarification.

That was my original intent, and I once again apologize for not being more clear about that.

It is not OK to hijack other issues…

Again, I did not desire to do so.

…and keep screaming for the feature you want when you have been told in no unclear terms “absolutely not, but perhaps in the future, though unlikely” and have been told exactly what “in the future” actually means and why it can only be considered again at such time.

…

Please forgive for being impatient enough at the time to want a more specific answer as to what tasks needed to be dealt with prior to any reconsideration of any of my contributions, however small they are.

…

This issue/thread is about the merging of projects, not features. …

I understand that. I just thought that it might be advantageous for the features I've mentioned in this thread to be more consistent between the two projects even if they still maintained some differences, and @MikeMcQuaid apparently agrees with me on this.

… It is already big enough to read, …

That's true, but I didn't think that inter-project feature consistency was that big of an addition. If it is, then I'd be happy to move discussion of that to another thread (pending its creation if such a thread should be created by a maintainer and not an end-user like myself.) I'd also be happy to help test said inter-project feature consistency's implementation once it starts being created.

…and we’re still waiting on the replies of other maintainers. …

If that precludes end-user feedback for the time being, then I'll willingly withdraw myself from this discussion until such a time as end-user feedback is sought by said maintainers, though I still wish to follow this discussion and see how things go.

… If you can’t take a “no” to your idea, when the reasoning has been explained multiple times, then I kindly ask you to leave.

Please pardon me for intruding, then, as I'll leave you to work in peace. I will, however, be available for comment if necessary.

[MikeMcQuaid]

@MikeMcQuaid Another question: how would we deal with our other repos? I’m concerned specifically with cases like caskroom/versions. From the way homebrew handles taps, that repo is called homebrew-versions, but another repo with that name already exists in homebrew. So we’d need to rename those, or is there a better way of handling it?

@vitorgalvao We could either migrate those things to homebrew/homebrew-versions or have caskroom/homebrew-versions or whatever. Basically: any number of options.

[MikeMcQuaid]

I understand that. I just thought that it might be advantageous for the features I've mentioned in this thread to be more consistent between the two projects even if they still maintained some differences, and @MikeMcQuaid apparently agrees with me on this.

I think this is up to the Cask team and @vitorgalvao. I figured you were part of that existing team.

If that precludes end-user feedback for the time being, then I'll willingly withdraw myself from this discussion until such a time as end-user feedback is sought by said maintainers, though I still wish to follow this discussion and see how things go.

I think with such things end-user feedback is not really that valuable until we have technical contributions. If you'd like to contribute technically, that would be great and I'd love to help you learn.

[fanquake]

@MikeMcQuaid Did you have some sort of timeframe/roadmap in mind for doing this? What are going to be the major sticking points?

[MikeMcQuaid]

I'm prepared to do work on this and help out but the timeframe and roadmap is up to the Cask core developers.

[vitorgalvao]

@maxnordlund All help is welcome.

Your suggestion does go against the rest of the goals/functionality, though, for various reasons:

• We want to reduce duplication, not add it.
• Mixing formulas and casks in the same repo is a big no (see replies to that comment).
• caskroom/unofficial’s idea is very far removed from that. It’s essentially caskroom/use-at-your-own-risk, but with a shorter name. It’s the dump for correct casks that should be in the main repo but can’t for same reason (walled downloads, for example).

[maxnordlund]

• We want to reduce duplication, not add it.

Not sure if this would do that. For me it seams like you'll need to extend the Cask DSL to support building apps from source? Or is the idea to have a unified Formulae DSL?

To avoid needing to extend the Cask DSL, why not just use the existing one? That was my idea anyways, but I've may very well have missed something.

• Mixing formulas and casks in the same repo is a big no (see replies to that comment).

Yes I did read that, and for any other repo it is definitely the right thing. But it would be done for the unoffical repo. Here I would think that the Cask maintainers would still be the owners, and hopefully the Formulae would not need to be updated (perhaps just the version/sha), since they represent the recipe to build the app in question.

On the other hand, you could extend the Formulae DSL to support installing the app, if it's not already possible. But considering that brew links, and the current plan for cask is to move, it might be hard(er) to do.

• caskroom/unofficial’s idea is very far removed from that. It’s essentially caskroom/use-at-your-own-risk, but with a shorter name. It’s the dump for correct casks that should be in the main repo but can’t for same reason (walled downloads, for example).

Well, in this thread at least it was mentioned as the place for unofficial .app bundles, or that was how I read it. If it is you're you-are-on-your-own-good-luck-have-fun repo, then it might be OK for it to have different rules regarding mixing Formulae and Cask.

I hope this explains my reasoning better, but it is just a suggestion nothing more. It's hard to have a nice tone of voice in writing, as it always seams so harsh, but it's not my intention. I apologize if that were the case here.

[MikeMcQuaid]

On the other hand, you could extend the Formulae DSL to support installing the app, if it's not already possible. But considering that brew links, and the current plan for cask is to move, it might be hard(er) to do.

It is already possible; they just aren't linked automatically and require running brew linkapps. If we have a dedicated tap for these things I think we could also run linkapps automatically too.

[vitorgalvao]

For me it seams like you'll need to extend the Cask DSL to support building apps from source?

That’s the last thing we need to do. It’s way out of our goals, and it’ll likely never happen. There’s no point to it, considering what we want for this tool. In addition, homebrew can already do all that (and they do for a few apps).

Regarding, caskroom/unofficial:

If it is you're you-are-on-your-own-good-luck-have-fun repo

That’s not what I said. I said “use-at-your-own-risk”. Difference being your wording suggests we’d offer no help/support with it, but that’s not the case. What I meant is though we do our best to have everything correct, there’s something that prevents us from doing so in those cases. We can’t verify the authenticity of their download urls, for example, so they might pose a security risk and you should proceed with caution.

then it might be OK for it to have different rules regarding mixing Formulae and Cask.

I stand by my comments in the other issue: different things, different structures, different goals, maintenance nightmare with no visible gains. Not worth it in the least.

I hope this explains my reasoning better, but it is just a suggestion nothing more. It's hard to have a nice tone of voice in writing, as it always seams so harsh, but it's not my intention. I apologize if that were the case here.

It was not, but I know the feeling, so now I’ll have to apologise from my side. Many times I also sound harsh in writing, but that is almost never my intention.

[maxnordlund]

On the other hand, you could extend the Formulae DSL to support installing the app, if it's not already possible. But considering that brew links, and the current plan for cask is to move, it might be hard(er) to do.

It is already possible; they just aren't linked automatically and require running brew linkapps. If we have a dedicated tap for these things I think we could also run linkapps automatically too.

I know this may a fair bit to late but I got reminded by #14053 and I just wanted to say that I think @MikeMcQuaid nailed it. Use the existing linkapps, and just special case a tap.

[alebcay]

@maxnordlund The general consensus has been reached that linking simply doesn't cut it for some Casks, and it's gotten to a point that such Casks are no longer corner cases that we can conveniently ignore. There are enough Casks that break in some way when being linked that we're eventually switching to copying them instead.

linkapps is neat, but linking simply isn't dependable enough for a project such as Homebrew Cask, whose sole project is to provide apps that, often (as we have slowly discovered), hate being linked. On the other hand, it makes sense for Homebrew to have it in order to link the occasional app that is included.

[MikeMcQuaid]

linkapps is neat, but linking simply isn't dependable enough for a project such as Homebrew Cask, whose sole project is to provide apps that, often (as we have slowly discovered), hate being linked. On the other hand, it makes sense for Homebrew to have it in order to link the occasional app that is included.

The difference between the two is actually somewhat more complex: all of Cask's .apps are self-contained so can me linked/copied/moved anywhere (although they generally are all intended to be put in /Applications). All (or almost all) of Homebrew's built-from-source .apps are not self-contained so cannot be copied or moved elsewhere so need to be linked.

[maxnordlund]

I would also add that it should be possible using configure flags/patches to make them link safe, since we're building them from source.

[fuzzy76]

Cask deals primarily with binary files, not building from source.

[MikeMcQuaid]

I would also add that it should be possible using configure flags/patches to make them link safe, since we're building them from source.

Without going into too much detail: it's a lot more complex to that; it's not about being link safe but having the bundle be relocatable and self-contained.

[toonetown]

Just as a question, would this (eventually) change the need to use cask on the command line? i.e. would you be able to brew install some-cask, or would you envision always running brew cask install some-cask?

I don't have a preference or an opinion one way or the other...it was just a thought that popped into my mind, and I was wondering what the plans would be around that.

[toonetown]

Never mind my question - I just saw this comment on another thread which basically answers it.

[MikeMcQuaid]

This was done ✨