Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

generic way to brew install foo --commit=sha #1738

Closed
timotheecour opened this issue Dec 27, 2016 · 4 comments
Closed

generic way to brew install foo --commit=sha #1738

timotheecour opened this issue Dec 27, 2016 · 4 comments

Comments

@timotheecour
Copy link
Contributor

Is there a way to install any package at a specific git commit or git tag ?
If not could we support it?
eg: I'd like to be able to do:

brew install foo --tag=v1.1.0-beta6
brew install foo --commit=eeeb0f2e8d0a77
brew install foo --tag=master

And formula for package foo would accept this git commit/tag as an argument and install that (generalizing the brew install foo --head command)

@vitorgalvao
Copy link
Member

That sounds good in theory. In practice, however, since software can change dramatically (install methods, dependencies, included tools) between versions, and formulas change even more than the software itself (to accommodate better ways to do things), your suggestion would either cause constant breaks (if it only changed, say, url and everything stayed the same) or it would need to somehow check the formula’s git history and grab the appropriate version, which is not only way harder, it would likely also cause breaks.

Both of those would be a support nightmare.

There’s a reason homebrew/versions exists.

@timotheecour
Copy link
Contributor Author

timotheecour commented Dec 27, 2016

  • often homebrew/versions isn't good enough (eg: ldc and dmd are not there, but are in homebrew-core)

  • I understand this wouldn't be guaranteed to work all the time (but neither does --head since HEAD can be broken at any time for some packages). However, this is small change compared to just supporting --head, and is much more flexible; it would be expected to work with recent enough commits/tags. It would provide a no-brainer installation for all recent enough commits of all packages supporting this --commit instead of --head.

  • As --head, this is useful mostly for development, or to benefit from recent bugfixes etc, without having to wait for someone to edit the brew formula. Bug fixes (etc) available at a specific commit/tag would automatically be available without waiting for updates in formula, without the downsides of only installing from --head (which can break arbitrarily often)

@vitorgalvao
Copy link
Member

vitorgalvao commented Dec 27, 2016

That doesn’t change the fact this would be a support nightmare. At least with homebrew/versions you can say “lets support this version correctly”. Your suggestion would automatically consider old versions of formulae that may themselves be broken or seemingly randomly not exist.

You can already do what you want in a more manual way. In github, go to the formula you want and click to check its history. Find the state you want, click to show the raw file and copy the URL. brew install {{that_url}}.

@MikeMcQuaid
Copy link
Member

We used to do this and, as @vitorgalvao points out, it was a support nightmare. It'll never be officially supported again because we cannot apply fixes to an arbitrary Git commit and old versions typically need updates to work on newer versions of macOS. If Homebrew/versions does not meet your needs (and it's worth noting in the future it will be merged into Homebrew/core but we'll never provide all old versions for all packages) you could either submit PRs to add the versions you want or maintain your old tap with old versions (in which you may well see why we're unwilling to support old versions indefinitely).

As for newer versions, --HEAD provides some this functionality and we welcome PRs to add devel do blocks for e.g. beta/RC versions. I think providing functionality to effectively run --HEAD on an arbtrirary revision would be something we'd accept a good PR for but won't be working on in the near future. Thanks for the clear explanation, though!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants