search gives bad results when there are multiple casks with the same tokens across repos

[vitorgalvao]

@claui Started working on this in #7906, but it was never finished.

Reported issues where we can see the problem: #19114, #27360.

[ibrokemypie]

Is anyone assigned to this? Or does this mean it is open to development by anyone who wants to submit a PR to close it?

[vitorgalvao]

Anyone can submit a PR for this.

[claui]

In terms of hours of work invested vs. work pending, I feel the unfinished PR is pretty close to completion.

By the time of my last commit (8 Dec 2014), the PR seemed feature complete but lacked a few tests. Now with two years having passed, it’s going to need a very thorough rebase on top of that.

I’d definitely love to finish it myself but right now I can’t. I have published all my work in progress to the branch refactor-search-by-name in my fork.

As @vitorgalvao said, anyone is free to work on it. Whoever wants to contribute should feel free to start from scratch – there are definitely quicker and simpler solutions than my large refactoring – or pick up my refactor-search-by-name branch if deemed helpful, and finish it, or gut it to their heart’s content. Either way, I’m excited and looking forward to having a search command that works like it should! 😊

[claui]

Just tried to rebase, ended up realizing there is no core anymore. I had completely forgotten 😳

Given the work already done was rather invasive, I can’t risk missing any relevant changes to the core while rebasing. So I really want a coherent Git history along the way. To achieve this, I’m thinking of multiple steps:

1. Rebase my work against the old /lib history, stopping at the last commit before the folder was finally deleted;

2. then, fork the Homebrew repo, branch off the initial commit from August;

3. commit the result of step # 1 onto that branch, and

4. continue rebasing normally against brew/master.

@caskroom/maintainers Any advice on a simpler solution? How did you go about similar problems in the past?

[reitermarkus]

Any advice on a simpler solution? How did you go about similar problems in the past?

Not really. Before moving the core we tried to merge as many core-related PRs as possible. The remaining ones were either closed due to lack of interest or merged relatively quickly afterwards.

[claui]

@reitermarkus Alright. I wonder though what would be the proper way to run any cask command from my dev working copy?

Before the transition, we used to have production-brew-cask and develop-brew-cask to switch modes. These used to be a piece of cake and was well documented.

I wonder where the equivalent thing in Homebrew is? I searched all the folders I deemed somewhat relevant, especially cmd, compat, dev-cmd, utils, and of course, the cask subtree, but nothing helpful has turned up there.

The consequence is that right now, I’m unable to run literally any command from my dev working copy of Homebrew. I have read all the docs – especially the three documents for maintainers – however, I have yet to find anything even remotely related to my issue, or even some kind of documentation on how to properly set up the Homebrew repo for development.

Nothing has worked so far. My simplest test case is: I look at the commit hash that brew --version gives me. So far, it has never been the one that corresponds to the HEAD of my repo.

Speaking of test cases: not only are the *-brew-cask scripts gone; someone also seems to have removed almost all of the test tasks from our Rakefile, which is in the new cask directory; this of course broke both rake spec and rake test. This apparantly happened some time after the transition. I wonder how you manage to run any core test cases now? (The documentation to Homebrew does mention “test bots” – however, these are probably not suitable for quickly testing along as I do changes to the core. Also, I can’t access those anyway.)

I understand that I’m obviously missing something – but what is it? After one day of achieving literally nothing, I’m running out of ideas and feel really confused and frustrated.

Would you mind please giving me a nudge in the right direction?

[reitermarkus]

Before the transition, we used to have production-brew-cask and develop-brew-cask to switch modes. These used to be a piece of cake and was well documented.

As far as I can remember the scripts were linking the development tap to Library/Taps/caskroom/homebrew-cask, so these were removed because they wouldn't have worked anymore, as the cask command is now integrated into Homebrew. Now you will either have to checkout to a different branch in the brew --repo while developing, or set up a separate Homebrew installation.

someone also seems to have removed almost all of the test tasks from our Rakefile

Tests are now run with brew cask-tests, which you can find in cask/cmd/brew-cask-tests.rb. However, I am currently in the process of merging these with brew tests.

[claui]

@reitermarkus Thanks for the pointers!

these were removed because they wouldn't have worked anymore, as the cask command is now integrated into Homebrew.

I don’t see how these two things are related. If we’re able to move a thing from A to B, how are we not able to modify those scripts to have them point to B instead of A, rather than throwing them away? That, admittedly, is a little beyond me.

To explain the itch behind my question, I’m going to let you guys in on the fact that I find myself having a embarrassingly hard time getting my dev environment up and running, especially when compared to the old HBC repo. This factoid is seemingly unrelated to the discussion at hand, and it might not have anything to do with Homebrew, and might very well have everything to do with my personal attitude, learning curve, or patience.

Except when it doesn’t.

The thing is, I was bitten once and became shy twice.

I do love Homebrew, you know. It’s a pleasure to use, and certainly an insanely convenient thing to have. I do also love brew update. But boy, have I learned to steer clear of ever standing in its merry way.

To back up my claim, I just need to look at my local working copy of HBC. Not a long time ago, I used to know exactly how, and when, to brew update, mainly thanks to develop-brew-cask. Never did I break, let alone lose, any of my work on a Cask or the HBC code.

Now compare to all this my stash of custom Homebrew formulae. I’ve written only a handful of those throughout the years. Nothing spectacular, and all of them for my own use. Sometimes my formulæ even have credentials in it because who cares. I used to tuck away all those formulae of mine in private branches but guess what? One day in 2015, my formulae started to disappear. My uncommitted changes? Vanish into thin air. My branches? Poof.

At first, I would not notice – because whatever it is that keeps snatching my formulae, the thing loves to strike silently, probably out of spite, or maybe because it secretly longs to be a ninja. By all means, it chooses not to blow up in my face like Git does whenever it finds a hairline crack in a whitespace (but wait … didn’t Homebrew use exactly Git behind the scenes?
… Oh right, they use git --ninja-surprise-purge now. My bad).

So, weeks pass, or even months, without me noticing my formulÆ are gone, until the day there is some upstream release, and off I go and update formula XY, or so I think! Actually, I can’t update formula XY because formula XY is gone. Gone because someone decided to change the color of the magic smoke inside brew update once again and the old smoke took with it all the feature branches, or stashes, with my custom formulæ in them. Do I bother? Keg no. I usually just shrug and move on with my life because I’m a big girl and I can cope with worse things than the fact that formula fidgeting and /usr/local magic are just not my thing.

But now that HBC is with Homebrew, all of that has changed, I guess? No more weaseling out of staying on top of how brew update works internally this season! Gonna have to bite the bullet and learn how to /usr/local, and how not to have my stuff ninja clobbered, right? Because – albeit admittedly on-and-off – I am a Homebrew-Cask core maintainer and I plan to remain one for years to come.

Yes, I’m going to bite the bullet and work on the HBC core in a private branch, below /usr/local, and stop complaining, and become a socially likeable person again. But before I do that, may I ask the simple question:

Why exactly is it that we cannot keep develop-brew-cask and production-brew-cask around?

Pinging @caskroom/maintainers for advice, consolation, or both.

[reitermarkus]

I don’t see how these two things are related. If we’re able to move a thing from A to B, how are we not able to modify those scripts to have them point to B instead of A, rather than throwing them away?

To be honest, I hadn't used these scripts before the merger, so there wasn't any incentive for me to make them work with the new setup, and nobody complained when they were gone. Also, keeping them in caskroom/cask doesn't really make sense anymore since this is now just a Tap.

My uncommitted changes? Vanish into thin air. My branches? Poof.

I can't say anything about this since I never had any trouble with brew update, but I understand your frustration and therefore need to have a decoupled development copy.

Why exactly is it that we cannot keep develop-brew-cask and production-brew-cask around?

Much of Homebrew-Cask is now intertwined with the Homebrew core, and will only get more integrated over time, so you will probably end up editing the Homebrew core anyway – develop-brew-cask, basically. Of course you could argue that the scripts can be adapted to edit the Homebrew core instead, but I think it's really a matter of personal preference if you want to work directly inside the production brew --repo or a second development copy.

[claui]

nobody complained when they were gone

It’s not that I’m trying to bring back this feature purely for my own convenience.

Let’s put ourselves – for a moment – in the shoes of a first-time code contributor who has just cloned the repo to, say, ~/myhomebrew, has written some code, and is now just about to test their first PR. Is it then not poor UX¹ to have them learn to their surprise that there’s no way to run the code they just built?

For the record, I’m positive that whoever removed the scripts did it with the best of intentions in mind. This doesn’t change how unhappy I am with the status quo though.

_{[1] or dev’s experience, in that instance}

---

I can't say anything about this since I never had any trouble with brew update.

Lucky you. 🍀 But even in a bug-free universe, where brew update plays with kittens, I believe the UX aspect (see above) is still crucial in the long run. Contributing code needs to be accessible for anyone with a GitHub account.

Also, keeping them in caskroom/cask doesn't really make sense since this is now just a Tap.

You’re correct; it’s not what I had in mind either.

Basically, what I want to achieve here is a workflow roughly similar to what we had before the transition. To get more precise, what I’m trying to do is this:

Step	Status	Description
Step 1	Normal	I choose a location in the filesystem, e. g. ~/myhomebrew.
Step 2	Normal	I git clone the complete Homebrew repo to ~/myhomebrew, either from the official repo or from my own fork.
Step 3	Normal → Linked	I’ve just written some code, now I need to test it. Thus, I run ~/myhomebrew/Library/Homebrew/developer/bin/develop-brew-cask.
Step 4	Linked	From now on, whenever I say brew cask xyz2, it’s going to do the exact thing that myhomebrew says instead of what /usr/local says 3.
Step 5	Linked → Normal	I have finished my work. Now I’m ready to go back to production mode; thus, I run production-brew-cask.
Step 6	Normal	All is back to normal. I can run brew update. In particular, my work in ~/myhomebrew is completely safe from the grasp of brew update.

_{[2] Let’s ignore the non-cask `brew xyz` commands for now. I’d be indifferent as to where those would point.}

_{[3] or whatever `$(brew --prefix)` happens to be at that moment}

What I’d love to do is write a script that simply does what the table says. At the moment, I have no idea how to go about that, or where to start looking for a solution. If I knew more about Homebrew, or if someone kindly helped me fill in the blanks, I would gladly implement the script myself, and then send a PR on its way.

Another strategy might be to do simple symlink trickery, like the old scripts did. (If I only had an idea what precisely needs to be linked, and to which target?) If I knew, I could restore develop-brew-cask and just change it there.

@caskroom/maintainers Any pointers?

[reitermarkus]

At the moment, I have no idea how to go about that, or where to start looking for a solution.

You know what? You could probably just simply call ~/myhomebrew/bin/brew aliased as dev-brew or the like. This way ~/myhomebrew is safe, even if you forget to run production-*.

[claui]

Thanks @reitermarkus, will try this right away!

[claui]

@reitermarkus The solution you suggested has worked great so far!
Exactly what I needed to get going. 👍

---

$ git clone [email protected]:claui/brew.git

Cloning into 'brew'...
[…]

$ cd brew

$ git tag 2.0.0

$ brew cask --version

Homebrew-Cask 1.1.5-66-g4ca2eaf
caskroom/homebrew-cask (git revision de574; last commit 2016-12-29)

$ bin/brew cask --version ← using bin/brew here

==> Tapping caskroom/cask
Cloning into '[…]/brew/Library/Taps/caskroom/homebrew-cask'...
[…]
Homebrew-Cask 2.0.0
caskroom/homebrew-cask (git revision de57; last commit 2016-12-29)

$ echo 'def hello; ohai "I’m in the dev repo"; end' > Library/Homebrew/dev-cmd/hello.rb

$ bin/brew hello ← using bin/brew here

==> I’m in the dev repo

[reitermarkus]

The solution you suggested has worked great so far!

Great to hear! 👍

[vitorgalvao]

The solution you suggested has worked great so far!

Can also attest to that. Used it for Homebrew/brew#1745.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[vitorgalvao]

@claui I seem to recall some discussion not too long ago (was already 2019?) in either the Homebrew/brew or Homebrew/homebrew-core repo about this very subject, and the conclusion being that it’s best to avoid having formulae in third-party taps whose tokens conflict with the official taps.

Is this issue still worth pursuing?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.