Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

brew tap "homebrew-" prefix requirement unnecessary and confusing #18792

Closed
Benjamin-Dobell opened this Issue · 9 comments

4 participants

@Benjamin-Dobell

Closed issues #18366, #18366 and #18432 are all attempting to deal with problem that probably shouldn't exist.

It doesn't seem to make any sense to require repos be named as username/homebrew- something. This naming scheme would imply that one Github user is supposed to be able to have multiple repos available that can be tapped, and that they can be distinguished by something. However, the Github website does not allow a user to fork the same repo more than once. So you can't reasonably expect users to have multiple homebrew repos in the first place.

Because you can't have multiple repos distinguished by something, it seems to me that the whole "homebrew-" prefix is redundant in the first place.

In addition to redundancy of the prefix, the current implementation is quite obscure and seems to oppose Github conventions / user expectations. For instance my homebrew fork is simply named Benjamin-Dobell/homebrew (which is the Github default when forking). After reading the manpage I expected I'd be able to tell users to:

brew tap Benjamin-Dobell homebrew

However, you're then prompted to enter your Github username and password. Which is very confusing as you then think that only Github users can "brew tap", which seems silly. Of course, once you enter your username and password it still doesn't work. The error given isn't really meaningful, so it's not immediately apparent why things fail. I actually had to look at tap.rb before I realised what was happening. This user experience doesn't really seem ideal.

Solution?

In the issues I've mentioned there was a reference to an "any-tap" command with semantics for tapping external repos. This seems like the only sane solution. Realistically there is no reason homebrew should be tightly coupled with Github. For full flexibility the tap command should probably work the following way.

brew tap <URL> [optional-commit-reference]

Where optional-commit-reference can refer to a commit by name, tag, branch-name or any regular git reference accepted by git checkout. In essence this could be implemented as:

git clone URL

if optional-commit-reference is provided, then:

git checkout optional-commit-reference

I don't really know ruby. But I'll take a crack at implementing this myself.

I haven't had the best luck getting what I believe to be perfectly reasonable pull requests merged (#18452) in the past. If someone sees a reason why my suggested solution fundamentally won't work, won't be merged for x reason, etc. Please let me know so I don't waste my efforts, and so we can come up with a solution that is suitable for all users.

@mikemcquaid
Owner

Taps are not forks of the main Homebrew repository. They are just a collection of formula files.

@Benjamin-Dobell

@mikemcquaid I most certainly did miss that!

This does make the redundancy argument pretty irrelevant. I could probably stretch the argument to say that the "homebrew-" prefix implies that you should have multiple repos for multiple sets of formulae, which I believe is indeed the intention. However, a user may well attempt to fork a common repo as the basis for their various tap repos. Github won't allow this. Hence a better solution might be to make use of branches/commit-refs etc. in one repo... But, that really is pretty desperate! :wink:

On the other hand, I believe the obscurity/usability argument holds firm. In addition to the unnecessarily tight coupling between Github and homebrew; I believe there is still enough cause for concern that warrants modifying the tap command to use the syntax I've suggested.

However, given the fact I missed the whole taps aren't forks thing, it's indeed very possible I'm still missing something! Please do let me know if that's the case.

@mikemcquaid
Owner

The homebrew- prefix matches the approach things like TextMate have taken and it has one massive benefit that is being overlooked (not just by you): it makes it much easier for both users and Homebrew to find (and potentially search) through lots of taps. Arguably as-is with the GitHub coupling it makes it possible to search through all taps and I think that's a good thing.

Homebrew and GitHub will remain tightly coupled to long as our issue tracker, community contributions, source code and update mechanism all rely on GitHub.

We could allow the tap command to potentially support non-standard taps but this would require an implementation that does so without breaking backwards compatibility so probably would need to be a separate option and flow. This isn't that easy, as previous attempts have discovered.

@Benjamin-Dobell

The homebrew- prefix matches the approach things like TextMate have taken and it has one massive benefit that is being overlooked (not just by you): it makes it much easier for both users and Homebrew to find (and potentially search) through lots of taps.

Fair enough.

Arguably as-is with the GitHub coupling it makes it possible to search through all taps and I think that's a good thing.

Homebrew and GitHub will remain tightly coupled to long as our issue tracker, community contributions, source code and update mechanism all rely on GitHub.

Making use of Github features is definitely a good thing. I certainly don't have an issue with that. However, the tight coupling with the way homebrew's features are implemented does not seem to be required in order for those features to be implemented. For instance, tapping a Git repo in order to obtain formulae doesn't seem to have much to do with Github.

Formula workflow issue?

I guess the way taps and pull requests are handled are what initially confused me, perhaps that is the root cause of my issue.

In order to get my formula merged, I must fork the homebrew repo, add my formula and make a pull request. Seems as my pull request wasn't merged and I wanted to make a release of my software, I looked at providing my formula as a tap. Hence, my confusion between tap repos and homebrew forks.

These two different workflows seem unnecessarily confusing. In order to properly contribute to the homebrew project and in the meantime provide my users with a quick release cycle I'd have to create both a tap repo, and a fork of homebrew containing the same formula.

Is there a particular reason formula are included in the main Homebrew repo and not a separate homebrew-formula repo? If the latter were the case users could fork homebrew-formula on Github which would simplify the work-flow and facilitate better indexing of third-party formula/taps (rather than searching for the "homebrew-" prefix).

@mikemcquaid
Owner

Yes, the pull-request and tap workflow are different. You don't want to provide a Homebrew fork for your users, just for submitting to us. You could (and should) maintain a tap for your users.

Ideally we want to have a homebrew-formula repo instead. This is a while off though; it's a big job to get it working. Even then though we will not want people to fork that but instead create their own, empty taps from scratch and add formulae to them (otherwise most taps will be 99% identical to the main formula repository).

A lot of what you are suggesting is sensible and valid but it's hard to implement given the current Homebrew codebase. Some of it we are planning on doing but some of it we won't get round to doing unless someone with motivation to do so does so.

@Benjamin-Dobell

@mikemcquaid That all seems reasonable to me. Also, thank you for the detailed responses; they're very much appreciated!

It's certainly not as big of an issue as I first believed. Nonetheless, I might as well see how I go making a "naive" attempt at implementing the external tap functionality. If my implementation isn't too embarrassing I'll make a pull request.

@jacknagel
Collaborator

@telemachus is working on stuff here: https://github.com/telemachus/homebrew-anytap

Might want to check it out rather than duplicate efforts.

@telemachus

For what it's worth: I've been using any-tap and any-untap instead of tap and untap steadily now for a couple of weeks. It works well, and although I don't think it will get pulled as such, I think it covers the two key things that most users seem to have wanted (and that I needed):

  • No requirement that repos be named homebrew-<something>
  • No requirement that repos be on GitHub

I need to write up contribution guidelines, but I'll probably remove the "Alpha use at your own risk" notice shortly.

@mikemcquaid
Owner

Closing this for now; we won't fix it but any-tap should meet your needs here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.